1
00:00:13,900 --> 00:00:15,600
Welcome to episode of the show, 
which talks about the 

2
00:00:15,600 --> 00:00:18,100
Technologies, projects, and 
people driving decentralisation 

3
00:00:18,100 --> 00:00:20,600
and the blockchain revolution. 
I'm service Equity. 

4
00:00:20,600 --> 00:00:22,600
Oh, and I'm here with my 
colleague for the AKA Ernst. 

5
00:00:22,700 --> 00:00:25,600
Today we're speaking with Nick 
Dodson, he's the co-founder and 

6
00:00:25,600 --> 00:00:28,100
CEO of few laps. 
They're building a fast modular 

7
00:00:28,100 --> 00:00:30,300
execution layer before you talk.
Look, Nick. 

8
00:00:30,300 --> 00:00:32,600
The about few labs and get into 
all the details. 

9
00:00:32,600 --> 00:00:34,600
Let me tell you first tell you 
about our sponsor this week. 

10
00:00:34,900 --> 00:00:38,500
Omni is your new favorite 
multi-chain, Mobile Wallet only 

11
00:00:38,500 --> 00:00:41,000
supports more than 25 protocol. 
So you can manage all your 

12
00:00:41,000 --> 00:00:43,700
assets in one place across all 
major EVMS. 

13
00:00:43,800 --> 00:00:47,400
Layer twos and nany vm's. 
But what's really special about 

14
00:00:47,400 --> 00:00:50,300
Omni is that you can do. 
All the most important things 

15
00:00:50,300 --> 00:00:52,600
about three directly in the 
wallet itself. 

16
00:00:52,700 --> 00:00:56,100
If you want to get yield, well, 
I'm Lee Omni allows you to get 

17
00:00:56,100 --> 00:00:58,800
the best apis with the zero fees
and three Taps. 

18
00:00:59,400 --> 00:01:05,000
If it's Making liquid staking 
lending via Ave or yield via 

19
00:01:05,500 --> 00:01:07,600
urine. 
Omni lets you do it. 

20
00:01:07,900 --> 00:01:13,000
If you need to exchange u.s. 
DC for eith on Adam or on Cosmos

21
00:01:13,200 --> 00:01:15,700
on the Aggregates, all major 
Bridges indexes. 

22
00:01:15,700 --> 00:01:20,100
So you can bridge and swap cross
all supportive networks in one 

23
00:01:20,100 --> 00:01:21,700
transaction directly in your 
wallet. 

24
00:01:21,700 --> 00:01:24,400
That's pretty cool. 
If you love it if he's Omni 

25
00:01:24,400 --> 00:01:27,500
offers the broadest NFC support 
of any wallet, so you can 

26
00:01:27,500 --> 00:01:29,800
connect and manage your favorite
entities across. 

27
00:01:29,900 --> 00:01:33,700
All chains in one place on the 
is, truly the easiest way to use

28
00:01:33,700 --> 00:01:36,100
web three. 
And most importantly on the is 

29
00:01:36,100 --> 00:01:39,300
fully self custodial. 
That's really important meeting 

30
00:01:39,300 --> 00:01:42,200
that you never have to trust 
anyone with your assets other 

31
00:01:42,200 --> 00:01:46,000
than yourself if you want. 
You can even use omnes Ledger 

32
00:01:46,000 --> 00:01:48,200
integration which is also cool 
feature. 

33
00:01:49,100 --> 00:01:51,700
So the all your fun. 
Stay on your Hardware wallet. 

34
00:01:51,900 --> 00:01:54,600
So join tens of thousands of 
users on this next Generation 

35
00:01:54,600 --> 00:01:58,400
wallet by downloading today on 
iOS or Android at army.mil. 

36
00:02:01,200 --> 00:02:04,600
Nick, thank you for joining us 
on this week's episode of 

37
00:02:04,600 --> 00:02:07,500
epicenter. 
Yeah, let's maybe start off by 

38
00:02:07,700 --> 00:02:10,100
talking about your background. 
So you were previous existence. 

39
00:02:10,100 --> 00:02:13,700
I think you were one of the 
earliest employees there. 

40
00:02:14,300 --> 00:02:16,600
What was your role and what kind
of stuff are you building? 

41
00:02:17,400 --> 00:02:20,000
Yeah, so first of all, yeah, 
thanks. 

42
00:02:20,000 --> 00:02:23,600
Thanks for having me. 
Yeah, consensus. 

43
00:02:24,200 --> 00:02:27,900
I started initially. 
I didn't think I was early with 

44
00:02:27,900 --> 00:02:29,800
consensus, although I did find 
out. 

45
00:02:29,900 --> 00:02:33,900
Out later on in time that I 
think it was like number 15 or 

46
00:02:33,900 --> 00:02:38,600
16 or something like that. 
And initially, I was brought in 

47
00:02:38,700 --> 00:02:42,700
to basically build out some 
early stage apps on ethereum. 

48
00:02:42,700 --> 00:02:46,700
So, some of the first apps on 
ethereum were, you know, 

49
00:02:46,708 --> 00:02:50,900
basically really simple things. 
And there was one exchange and 

50
00:02:50,900 --> 00:02:53,700
then there was something I was 
working on, which was way fun 

51
00:02:53,700 --> 00:02:55,700
than, and another project called
boardroom. 

52
00:02:56,300 --> 00:02:59,800
So, both those projects were 
projects. 

53
00:03:00,000 --> 00:03:04,900
Consensus wanted to kind of fund
and help and grow. 

54
00:03:05,200 --> 00:03:10,800
So I was working working on that
with them and then and then 

55
00:03:10,800 --> 00:03:14,600
after that, I started to work on
some libraries and other things 

56
00:03:15,200 --> 00:03:18,600
which are still used in things 
like meta masks and stuff like 

57
00:03:18,600 --> 00:03:21,100
that. 
So also wrote a fair bit of 

58
00:03:21,100 --> 00:03:26,200
infrastructure did a fair bit of
writing and yeah, that would 

59
00:03:26,200 --> 00:03:28,600
kind of Encompass consensus for 
me. 

60
00:03:30,100 --> 00:03:33,800
Something like that. 
He then left consensus and you 

61
00:03:33,800 --> 00:03:36,600
started few Labs with John 
Adler. 

62
00:03:37,400 --> 00:03:39,700
How did you meet? 
And how did you decide to work 

63
00:03:39,700 --> 00:03:41,700
together? 
Yes. 

64
00:03:41,700 --> 00:03:46,600
Oh John, I met in the Toronto 
office of consensus and 

65
00:03:47,200 --> 00:03:50,000
initially. 
He came came into the office one

66
00:03:50,000 --> 00:03:55,300
day and said that he had solid 
scalability for etherium, or for

67
00:03:55,700 --> 00:03:58,100
ebm base. 
Blockchains things like that and

68
00:03:59,000 --> 00:04:02,600
initially, I felt Like here's 
the crazy guy in the office. 

69
00:04:03,000 --> 00:04:10,200
So I'd heard so many times this 
kind of like rhetoric or I've 

70
00:04:10,200 --> 00:04:12,200
just heard. 
I've heard it so many times that

71
00:04:12,400 --> 00:04:14,800
I didn't really pay much 
attention to it. 

72
00:04:14,800 --> 00:04:19,200
But you know, after I left 
consensus and, you know, wanted 

73
00:04:19,200 --> 00:04:22,400
to work on a few different 
pieces of infrastructure for 

74
00:04:22,400 --> 00:04:24,600
theorem some wallets, things 
like that. 

75
00:04:25,000 --> 00:04:28,800
I started to think about what 
technology we had available for 

76
00:04:28,800 --> 00:04:31,800
Theory. 
I'm too To actually do scaling. 

77
00:04:31,800 --> 00:04:34,900
And at the time, there was 
nothing like layer 2 or nothing,

78
00:04:34,900 --> 00:04:40,500
like anything that we have now, 
zzk, even it was very minimal. 

79
00:04:41,100 --> 00:04:44,300
And basically, everyone was 
focused on payment channels or 

80
00:04:44,300 --> 00:04:46,900
plasma. 
Those Solutions weren't very 

81
00:04:46,900 --> 00:04:50,900
good and they were pretty 
subject to a lot of faulty kind 

82
00:04:50,900 --> 00:04:55,200
of thinking, or, you know, just 
technology that wasn't great or 

83
00:04:55,200 --> 00:04:58,400
wasn't, well architected. 
So, I sent John a message and 

84
00:04:58,400 --> 00:05:01,000
said, okay, you know, like what 
What was this stuff that you're 

85
00:05:01,000 --> 00:05:02,900
working on? 
And then he basically described 

86
00:05:02,900 --> 00:05:07,000
optimistic Roll-Ups to me and it
was like a three-hour 

87
00:05:07,000 --> 00:05:10,000
conversation, the cafe back and 
forth, but it's pretty convinced

88
00:05:10,000 --> 00:05:13,600
that that time, that this was 
something, you know, something 

89
00:05:13,600 --> 00:05:16,100
worth working on something worth
spending some time on. 

90
00:05:17,000 --> 00:05:20,600
So from that point, then we 
essentially started fuel right 

91
00:05:20,600 --> 00:05:22,700
there. 
So I was like, middle 2019, 

92
00:05:22,700 --> 00:05:25,500
something like that. 
Yes, that's cool. 

93
00:05:26,200 --> 00:05:29,400
I mean, so fuel is a project 
that I haven't like, followed 

94
00:05:29,500 --> 00:05:33,900
very much, but I mean, like, I'm
now much more involved. 

95
00:05:33,900 --> 00:05:37,800
I saying the cosmos space and, 
you know, Celestia has kind of 

96
00:05:37,800 --> 00:05:42,000
captured the captured, the 
narrative, and like modular 

97
00:05:42,000 --> 00:05:43,900
block chains has really captured
a lot of the narrative. 

98
00:05:43,900 --> 00:05:47,600
I think, in that space, I think 
it's a theory mm to, as well 

99
00:05:47,600 --> 00:05:49,900
with with theorem to after the 
merge. 

100
00:05:49,900 --> 00:05:52,700
Now, people are thinking about 
blockchain so much more modular 

101
00:05:52,700 --> 00:05:56,100
way. 
But yeah, like where does this 

102
00:05:56,100 --> 00:06:00,400
all fit together? 
And in this module is stack of 

103
00:06:00,400 --> 00:06:04,700
Education, settlement, consensus
and data availability. 

104
00:06:05,100 --> 00:06:08,100
Where does fuel set? 
And how does it interact with 

105
00:06:08,100 --> 00:06:12,800
these other layers? 
Yes, I think to start with that 

106
00:06:12,800 --> 00:06:17,200
question. 
I think it starts with just we 

107
00:06:17,400 --> 00:06:21,400
like the blockchain systems that
we've been building. 

108
00:06:21,400 --> 00:06:24,400
So, so initially going from 
Bitcoin and then going into The 

109
00:06:24,700 --> 00:06:29,400
real coins and then going into a
cerium, you know, we I think the

110
00:06:29,400 --> 00:06:32,700
original designers didn't really
know all the exact constraints 

111
00:06:32,700 --> 00:06:34,400
or how things would actually 
play out with those 

112
00:06:34,400 --> 00:06:36,200
architectures. 
So when you put them together in

113
00:06:36,200 --> 00:06:39,600
Ashley you're not so sure as to 
how you want to construct them 

114
00:06:40,200 --> 00:06:43,400
and that's going to create 
architectural issues and because

115
00:06:43,400 --> 00:06:47,500
of the fact that blockchains are
immutable and they, they work in

116
00:06:47,500 --> 00:06:50,100
a specific Way, backwards, 
compatibility is something that 

117
00:06:50,600 --> 00:06:55,600
is very important to retain and 
so this Ends up kind of burying 

118
00:06:55,600 --> 00:06:58,000
you and your decisions a little 
bit because you can't break 

119
00:06:58,000 --> 00:07:00,900
backwards compatibility. 
So the decisions you make early 

120
00:07:00,900 --> 00:07:03,200
on with the blockchain are the 
ones that you typically have to 

121
00:07:03,200 --> 00:07:04,800
stick with us for a very long 
time. 

122
00:07:05,300 --> 00:07:08,400
And unfortunately, for aetherium
you know, theory of made a lot 

123
00:07:08,400 --> 00:07:12,700
of very interesting and some 
really good design decisions at 

124
00:07:12,700 --> 00:07:15,300
the early kind of stage of the 
project. 

125
00:07:15,800 --> 00:07:18,200
But unfortunately, just due to 
its nature and due to the way 

126
00:07:18,200 --> 00:07:22,400
that the architecture works, 
there was too many things that 

127
00:07:22,400 --> 00:07:27,600
were designed. 
Not for scale and it ended up 

128
00:07:27,600 --> 00:07:32,000
really hampering theorems 
ability to kind of get to scale 

129
00:07:32,000 --> 00:07:35,700
and I think across the ecosystem
whether it's like Cosmos or any 

130
00:07:35,700 --> 00:07:39,800
other blockchain, all of them 
actually suffer from a lot of 

131
00:07:39,800 --> 00:07:43,600
processing issues that are 
really related to how much 

132
00:07:43,600 --> 00:07:47,500
processing you can squeeze out 
of a node to process 

133
00:07:47,500 --> 00:07:52,200
transactions. 
And so we've only really over 

134
00:07:52,200 --> 00:07:56,700
the past few years actually, 
Figured out ways to kind of 

135
00:07:56,700 --> 00:08:00,200
better utilize the nodes and 
better utilize processing in a 

136
00:08:00,200 --> 00:08:02,900
blockchain setting or in a 
peer-to-peer setting to actually

137
00:08:02,900 --> 00:08:06,100
resolve some of these 
scalability issues and namely 

138
00:08:06,100 --> 00:08:09,100
parallel transaction. 
Execution for theorem is a big 

139
00:08:09,100 --> 00:08:11,900
one and there's very few chains 
that actually try to address 

140
00:08:11,900 --> 00:08:15,600
that or solve that and that's 
just using all the threads and 

141
00:08:15,608 --> 00:08:18,100
cores of your CPU to actually 
process transactions. 

142
00:08:18,100 --> 00:08:21,900
And another one is just that the
actual virtual machines 

143
00:08:21,900 --> 00:08:26,000
themselves that we build smart 
Cracks on or build smart 

144
00:08:26,000 --> 00:08:29,600
contracts. 
To Target are also designed in a

145
00:08:29,600 --> 00:08:33,799
way, that is very constrained. 
And unfortunately is very, very 

146
00:08:33,799 --> 00:08:36,900
expensive. 
And so the virtual machines 

147
00:08:36,900 --> 00:08:39,700
we've typically used have not 
been flexible or not been 

148
00:08:39,700 --> 00:08:43,500
cognizant of all of the sort of 
physics of processing that you 

149
00:08:44,000 --> 00:08:47,400
typically see, with blockchains 
and blockchains are really weird

150
00:08:47,400 --> 00:08:52,000
machines because you need to 
price every operation, otherwise

151
00:08:52,000 --> 00:08:53,800
it's easy to bring the chain 
down. 

152
00:08:54,400 --> 00:08:56,300
And when you're pricing every 
operation, this ends up. 

153
00:08:56,300 --> 00:09:00,200
Creating a weird set of physics 
in the design where you know you

154
00:09:00,200 --> 00:09:05,000
need to design for pricing of 
operations, not just necessarily

155
00:09:05,300 --> 00:09:08,600
low-level operations or 
efficient operations. 

156
00:09:08,600 --> 00:09:11,700
Everything has to be accounted 
for in that in that field. 

157
00:09:11,700 --> 00:09:16,200
So when it comes to any one of 
these chains are any any Block 

158
00:09:16,200 --> 00:09:20,700
Chain itself, typically you see 
similar physics play out and you

159
00:09:20,700 --> 00:09:23,200
need to design a system that's 
going to be tailored for that 

160
00:09:23,200 --> 00:09:27,400
physic Physics. 
But on top of that, when it 

161
00:09:27,400 --> 00:09:30,500
comes to block chains right now.
I mean there's probably 

162
00:09:30,500 --> 00:09:32,500
thousands of blockchains out 
there. 

163
00:09:32,500 --> 00:09:37,300
I think Cosmos you know and and 
that ecosystem has been great 

164
00:09:37,400 --> 00:09:41,400
instead of addressing some 
aspects of blockchain scale or 

165
00:09:41,900 --> 00:09:45,200
or you know basically getting 
blockchains to Global adoption 

166
00:09:45,200 --> 00:09:48,100
which is effectively in a 
developing tenements and these 

167
00:09:48,100 --> 00:09:52,600
consensus systems and I think a 
lot of their work has been 

168
00:09:52,600 --> 00:09:54,600
extremely beneficial for for 
that setting. 

169
00:09:54,600 --> 00:09:58,000
And as well also allowing other 
devs to create these sort of, 

170
00:09:58,200 --> 00:09:59,900
you know, more K specific 
chains. 

171
00:10:00,500 --> 00:10:02,600
I think for aetherium, it's 
really just bringing us the 

172
00:10:02,600 --> 00:10:05,900
ability to do smart contracts 
and do kind of global 

173
00:10:05,900 --> 00:10:08,800
settlement. 
Even though the machine is not 

174
00:10:08,800 --> 00:10:12,800
nice to process, and the system 
is not necessarily a great 

175
00:10:12,800 --> 00:10:16,100
system for scale. 
You know, I think with the 

176
00:10:16,100 --> 00:10:19,200
Advent of sort of layer 2 and 
how we're approaching execution.

177
00:10:19,200 --> 00:10:21,100
Now, we're sort of addressing 
that. 

178
00:10:21,100 --> 00:10:25,600
And basically, how See things 
playing out in terms of the 

179
00:10:25,600 --> 00:10:28,400
ecosystem. 
I think app-specific chains are 

180
00:10:28,400 --> 00:10:31,900
really important. 
I think they can solve certain 

181
00:10:32,000 --> 00:10:34,600
case, specific issues with 
blockchain, where you can get 

182
00:10:34,600 --> 00:10:37,700
some benefits. 
I think Celestia solves this 

183
00:10:37,700 --> 00:10:42,500
problem of who's watching the 
data and we're because you get 

184
00:10:42,500 --> 00:10:46,400
that with you know State Channel
systems and other systems like 

185
00:10:46,400 --> 00:10:51,500
that where you know it comes 
down to for security that having

186
00:10:51,500 --> 00:10:53,800
a single source of data that a 
bunch of people. 

187
00:10:53,900 --> 00:10:57,800
We are using ends up being a lot
safer than spreading the data 

188
00:10:57,800 --> 00:10:59,700
into different silos where can 
just vanish. 

189
00:10:59,700 --> 00:11:03,100
And then you can never actually 
run or challenge or execute a 

190
00:11:03,108 --> 00:11:06,900
system in a global like 
peer-to-peer decentralized, like

191
00:11:06,900 --> 00:11:09,300
fault tolerance or censorship 
resistant way. 

192
00:11:10,000 --> 00:11:13,400
So Celestia is really trying to 
address that in a wholehearted 

193
00:11:13,400 --> 00:11:16,800
way and I think I think it does 
a pretty good job and then I 

194
00:11:16,800 --> 00:11:20,000
think as well theorem does a 
pretty good job of just being a 

195
00:11:20,000 --> 00:11:23,800
great settlement layer. 
I think the kind of bamboo 

196
00:11:23,900 --> 00:11:26,600
Increases we're going to see 
with like for a 44 and stuff 

197
00:11:26,600 --> 00:11:28,400
like that are going to are going
to help a lot. 

198
00:11:29,200 --> 00:11:32,900
But in terms of how I see all 
these things playing out to be, 

199
00:11:33,400 --> 00:11:36,500
it's always really hard to say, 
how the future is going to go. 

200
00:11:36,600 --> 00:11:41,200
But already, I'm starting to see
that across the board. 

201
00:11:42,000 --> 00:11:46,200
You know, we should not be so 
religious about how we execute 

202
00:11:46,200 --> 00:11:51,100
things on blockchains because 
essentially these architectures 

203
00:11:51,100 --> 00:11:54,400
are still very new and there's a
lot of room to grow and improve.

204
00:11:54,400 --> 00:11:58,400
And so with fuel, we look to 
build an execution layer that 

205
00:11:58,400 --> 00:12:02,700
can be extremely modular and fit
into many of these different 

206
00:12:02,700 --> 00:12:06,200
settings or be on top of 
different settings and be 

207
00:12:06,200 --> 00:12:09,700
configurable in different ways. 
And so trying to maximize the 

208
00:12:09,700 --> 00:12:12,300
amount of execution, the 
blockchains can do in general 

209
00:12:12,300 --> 00:12:16,400
and not trying to be alter a 
maximalist about like our own 

210
00:12:16,400 --> 00:12:19,600
system or our own chain. 
But instead look at all these 

211
00:12:19,600 --> 00:12:22,100
existing chains and go. 
Well, how could we help someone 

212
00:12:22,100 --> 00:12:23,800
like gnosis chain or how can we 
help? 

213
00:12:23,900 --> 00:12:28,300
Unlike a cosmos chain or 
tenement chain or aetherium, how

214
00:12:28,300 --> 00:12:31,700
can we help them with their 
scalability goals, but also 

215
00:12:31,700 --> 00:12:36,000
bring them a system. 
That's complete from a scaling 

216
00:12:36,000 --> 00:12:39,700
and devex perspective. 
And something that I think 

217
00:12:39,700 --> 00:12:44,100
developers would be really 
excited to use and that really 

218
00:12:44,100 --> 00:12:46,500
does address a lot of the 
scalability issues that we see 

219
00:12:46,500 --> 00:12:49,200
in the space. 
So feels really trying to tackle

220
00:12:49,200 --> 00:12:53,000
execution and devex. 
As it's like, core kind of 

221
00:12:53,000 --> 00:12:56,500
thesis and we're sort. 
Out of letting settlement and 

222
00:12:56,500 --> 00:13:00,600
data availability and things 
like consensus, you know, be 

223
00:13:00,600 --> 00:13:06,000
dealt with by other systems and 
that's the way I sort of sort of

224
00:13:06,000 --> 00:13:11,100
see it fuel will have many 
execution layer settling on 

225
00:13:11,100 --> 00:13:13,900
etherium. 
Probably some with Celestia's 

226
00:13:13,900 --> 00:13:16,100
data. 
Availability some of the theorem

227
00:13:17,100 --> 00:13:19,200
and some with no data 
availability, so like a 

228
00:13:19,200 --> 00:13:23,300
committee and I think that is an
appropriate way to solve 

229
00:13:23,300 --> 00:13:26,000
different problems. 
Jack's scalability needs while 

230
00:13:26,000 --> 00:13:29,400
still retaining the etherium 
community and you know, all the 

231
00:13:29,400 --> 00:13:31,200
benefits that a theorem brings 
to the table. 

232
00:13:32,500 --> 00:13:35,200
So maybe that gives you some 
answers. 

233
00:13:35,200 --> 00:13:37,600
I sort of tried to walk through 
a bunch of different topics 

234
00:13:37,600 --> 00:13:39,400
there. 
How many ounces? 

235
00:13:39,400 --> 00:13:41,900
So many ideas? 
I have even more questions now. 

236
00:13:42,000 --> 00:13:45,000
So best, there's certainly a lot
to unpack yet. 

237
00:13:45,000 --> 00:13:48,600
So maybe before we kind of dive 
into the nitty-gritty details 

238
00:13:48,600 --> 00:13:50,700
about kind of, for instance, how
you actually managed to 

239
00:13:50,700 --> 00:13:54,800
parallelize transaction commits 
computation, And so on, let's 

240
00:13:54,800 --> 00:13:57,200
kind of look at the at the big 
picture, right? 

241
00:13:57,200 --> 00:14:01,000
So basically, if you have, if 
you have in the blockchain 

242
00:14:01,000 --> 00:14:03,500
world, you have different 
functions that are kind of that 

243
00:14:03,500 --> 00:14:07,400
are fulfilled traditionally or 
if I say theorem. 

244
00:14:07,400 --> 00:14:11,500
So for instance, you had data 
availability consensus 

245
00:14:11,800 --> 00:14:15,400
settlement, and execution and 
basically everything was done by

246
00:14:16,000 --> 00:14:18,600
bayi theorem. 
And now after the match, I mean,

247
00:14:18,600 --> 00:14:22,200
basically data availability this
kind of already, there were 

248
00:14:22,200 --> 00:14:24,900
pretty good Integrations. 
Even before the marriage. 

249
00:14:24,900 --> 00:14:29,100
So things like are we for 
instance but after the match we 

250
00:14:29,100 --> 00:14:31,600
now have consensus and execution
clients. 

251
00:14:31,600 --> 00:14:33,100
Right? 
And in principle they kind of 

252
00:14:33,100 --> 00:14:37,700
run independent of each other 
and then you still have, you 

253
00:14:37,700 --> 00:14:42,300
know, this extra execution layer
on top of everything and 

254
00:14:42,300 --> 00:14:45,600
basically that's kind of like 
the word of are touzani Theory. 

255
00:14:45,600 --> 00:14:48,900
Mm. 
So fewer did actually start out 

256
00:14:48,900 --> 00:14:52,400
as an optimistic roll up on the 
a theory. 

257
00:14:52,400 --> 00:14:57,200
Well, basically, just that So, 
what exactly does the pivot to a

258
00:14:57,200 --> 00:14:59,500
module execution? 
They are actually entail. 

259
00:14:59,600 --> 00:15:02,000
So what, what what, what is that
even? 

260
00:15:02,000 --> 00:15:05,700
How is it different from an heir
to if it then satyrs to a 

261
00:15:05,708 --> 00:15:06,900
theory? 
Many ways to me? 

262
00:15:06,900 --> 00:15:09,300
That sounds like exactly the 
same thing. 

263
00:15:09,900 --> 00:15:12,600
Yeah. 
So the distinction we make is 

264
00:15:12,600 --> 00:15:16,900
that a lot of the layer 2 is in 
the space right now, are now 

265
00:15:16,900 --> 00:15:21,000
really designed for extremely 
high bandwidth systems, so 

266
00:15:21,000 --> 00:15:23,400
they're really optimized for a 
different. 

267
00:15:23,900 --> 00:15:25,700
Two fundamentally different 
problem, which is really just 

268
00:15:25,700 --> 00:15:29,600
trying to fit as many sort of 
transaction B onto a theory of 

269
00:15:29,600 --> 00:15:32,500
as possible. 
And the thing is, when you open 

270
00:15:32,500 --> 00:15:35,100
up the data availability and 
when you just kind of look at a 

271
00:15:35,108 --> 00:15:38,400
system with a lot more data 
availability like Celestia you 

272
00:15:38,400 --> 00:15:41,900
really end up having to design a
completely different style of 

273
00:15:41,900 --> 00:15:45,300
execution system. 
That is not necessarily you 

274
00:15:45,300 --> 00:15:48,800
know, one that like an evm based
system could ever accomplish 

275
00:15:48,800 --> 00:15:51,300
which is really trying to give 
you full like parallel 

276
00:15:51,300 --> 00:15:55,000
transaction execution and trying
to Leverage All of that that 

277
00:15:55,000 --> 00:15:57,000
data or as much of that data as 
possible. 

278
00:15:57,400 --> 00:16:00,200
So the distinction we make is 
that module executioner is 

279
00:16:00,200 --> 00:16:03,500
really designed for a high 
bandwidth system. 

280
00:16:03,500 --> 00:16:08,300
So it's a distinction from, or 
away from layer 2 is even though

281
00:16:08,300 --> 00:16:11,900
it can take the form of a layer 
to specifically and can take the

282
00:16:11,900 --> 00:16:14,000
form of, like, announcements to 
grow up on a theorem. 

283
00:16:14,800 --> 00:16:18,100
It can also take other forms 
such as like, you know, 

284
00:16:18,200 --> 00:16:22,200
Palladiums or other things that,
you know, we've heard kind of 

285
00:16:22,400 --> 00:16:25,600
discussions around as well. 
It can also be its own layer 1 

286
00:16:25,800 --> 00:16:29,300
so it can be configured in many 
different settings, but the, the

287
00:16:29,300 --> 00:16:32,900
major distinction is that it's 
designed for a high bandwidth 

288
00:16:33,100 --> 00:16:36,800
modular Block Chain. 
And this is really one that you 

289
00:16:36,800 --> 00:16:39,400
really only see, currently with 
something like Celestia, but 

290
00:16:39,600 --> 00:16:42,800
you'll probably start to see a 
little more of with etherium as 

291
00:16:42,800 --> 00:16:46,300
they try to expand their their 
bandwidth. 

292
00:16:46,700 --> 00:16:50,600
So we just make a distinction 
between modules execution, and, 

293
00:16:51,000 --> 00:16:55,000
and layer to specifically just 
because Trying to leverage all 

294
00:16:55,000 --> 00:16:57,800
the benefits that modular block 
chains, give us and high 

295
00:16:57,800 --> 00:17:02,600
bandwidth is like a key aspect 
of that versus like a typical 

296
00:17:02,600 --> 00:17:05,599
like layer to which is more 
awesome rise to design. 

297
00:17:05,599 --> 00:17:08,700
For essentially trying to work 
on a theory of right now which 

298
00:17:08,700 --> 00:17:13,099
is like trying to pack bits and 
bites onto etherium, which is 

299
00:17:13,099 --> 00:17:14,800
not necessarily a great 
optimization. 

300
00:17:14,800 --> 00:17:19,200
Once you, you know, actually 
tried to do tens of thousands of

301
00:17:19,200 --> 00:17:21,200
transactions, that's like the 
least of your worries. 

302
00:17:22,000 --> 00:17:24,900
Do you think this is this 
assessment is going to change 

303
00:17:24,900 --> 00:17:27,500
when we get if and when we get 
dang sharding. 

304
00:17:28,700 --> 00:17:31,300
I don't think so. 
I mean, I think, you know, for 

305
00:17:31,300 --> 00:17:35,200
fuel and what we're trying to 
build, like we're looking to 

306
00:17:35,200 --> 00:17:38,200
leverage all the data that we 
can on ethereum as much as 

307
00:17:38,200 --> 00:17:41,700
possible, just like any other 
players who are outsourced roll 

308
00:17:41,700 --> 00:17:43,900
up. 
But at the same time, we're also

309
00:17:43,900 --> 00:17:46,700
designing our system for 
extremely high bandwidth. 

310
00:17:47,100 --> 00:17:51,600
That's far beyond what I think 
for a 44, or dank charting, or 

311
00:17:51,600 --> 00:17:54,400
any of these kind of upgrades 
would entail. 

312
00:17:54,900 --> 00:17:58,300
And that amount of data can be 
significantly. 

313
00:17:58,400 --> 00:18:01,400
Larger. 
So whatever Celestia is going to

314
00:18:01,408 --> 00:18:04,500
pull off and as well, 
potentially even if we just 

315
00:18:04,500 --> 00:18:08,500
wanted to run as a side chain. 
So we didn't want to use data, 

316
00:18:08,500 --> 00:18:11,800
availability of Celestia. 
We could open the bandwidth 

317
00:18:11,800 --> 00:18:15,100
significantly. 
So you know, you have to sort of

318
00:18:15,100 --> 00:18:18,900
plan for like a a lot of 
bandwidth and not just 

319
00:18:18,900 --> 00:18:21,300
necessarily the bandwidth like 
what aetherium has or what 

320
00:18:21,300 --> 00:18:24,400
Celestia has. 
So for us, it's just full Paulo 

321
00:18:24,400 --> 00:18:27,000
transaction execution across the
board that allows us to 

322
00:18:27,000 --> 00:18:30,400
capitalize on all of that. 
If you're a developer right now 

323
00:18:30,400 --> 00:18:33,100
and like you're thinking of 
building an app there, you know,

324
00:18:33,100 --> 00:18:37,800
there are any number of ways you
could do that and also like 

325
00:18:37,800 --> 00:18:40,400
several different platforms and 
programming languages in 

326
00:18:40,400 --> 00:18:43,800
ecosystems. 
But looking looking at it purely

327
00:18:43,800 --> 00:18:48,800
from a like stack perspective, 
what are the consideration? 

328
00:18:48,800 --> 00:18:57,100
One should take into account 
when choosing to go modular or 

329
00:18:57,500 --> 00:19:01,400
like you've got this great A 
graph on on a blog post, where 

330
00:19:01,600 --> 00:19:04,000
you've got, like, on one side, 
monolith, eccentric. 

331
00:19:04,000 --> 00:19:08,000
And and then on the other axis 
are monolithic Centric and 

332
00:19:08,000 --> 00:19:11,300
modular eccentric on one axis. 
And then data, availability, 

333
00:19:11,300 --> 00:19:13,300
consensus settlement. 
And the execution on the other 

334
00:19:13,300 --> 00:19:17,700
end, there's like, six different
ways that one can build it on a 

335
00:19:17,700 --> 00:19:18,900
blockchain. 
Yeah. 

336
00:19:18,900 --> 00:19:22,200
What are the considerations that
one needs to take into account, 

337
00:19:22,200 --> 00:19:25,300
when like, wanting to choose, 
whether to do, like, Sovereign, 

338
00:19:25,300 --> 00:19:27,800
roll-up, or Selman, roll-up, or 
like Celestia? 

339
00:19:27,800 --> 00:19:31,300
Mm, which I'm Not even really 
sure what it is or like the 

340
00:19:31,300 --> 00:19:34,100
Lydia more, right? 
Yeah. 

341
00:19:34,100 --> 00:19:37,000
So, I mean, I think the spectrum
is always going to be between 

342
00:19:37,000 --> 00:19:41,200
something like price security 
and and and and that's it. 

343
00:19:41,200 --> 00:19:45,200
So you're you're basically in a 
situation where you're looking 

344
00:19:45,200 --> 00:19:48,100
at, well, how much does it cost 
for me to actually deploy and 

345
00:19:48,100 --> 00:19:50,200
run my system? 
And then how much security do 

346
00:19:50,200 --> 00:19:54,400
actually need from the system? 
And, and then, finally, likely 

347
00:19:54,400 --> 00:19:58,100
the case, where do I want assets
to be able to settle to or be 

348
00:19:58,100 --> 00:19:59,300
interoperable? 
Go with you. 

349
00:19:59,300 --> 00:20:00,600
No. 
At the at these sort of end 

350
00:20:00,600 --> 00:20:05,300
stage if there is going to be a 
lot of assets there and as well,

351
00:20:05,300 --> 00:20:07,800
what kind of ecosystems you want
exposure to? 

352
00:20:07,800 --> 00:20:13,000
So, with fuel, we don't work 
extremely agnostic to these 

353
00:20:13,000 --> 00:20:16,200
variables. 
You can deploy to a fuel 

354
00:20:16,200 --> 00:20:20,100
execution layer that will be low
in price, but potentially, you 

355
00:20:20,100 --> 00:20:23,000
know, less security. 
And then you can deploy to a 

356
00:20:23,000 --> 00:20:26,100
layer that has a higher price 
point, but also a higher grade 

357
00:20:26,100 --> 00:20:29,900
of security and you can still 
have The benefits of settling on

358
00:20:29,900 --> 00:20:33,300
something like aetherium and 
having access to the theory of 

359
00:20:33,300 --> 00:20:36,800
ecosystem, the the fact that the
the bridges will interoperate 

360
00:20:36,800 --> 00:20:40,600
with the theorem, you know, 
very, very easily but as well, 

361
00:20:40,600 --> 00:20:44,800
if there's other chains, such as
something like nose is chain or 

362
00:20:44,800 --> 00:20:47,800
something else like that where 
you're going to have execution 

363
00:20:47,800 --> 00:20:52,900
list as well, then, you know, 
execution can can also happen 

364
00:20:52,900 --> 00:20:54,200
there. 
And you can also deploy those 

365
00:20:54,200 --> 00:20:58,900
systems and so or if it's Cosmos
chains or if it's layer Ones 

366
00:20:58,900 --> 00:21:02,100
using a fuel execution layer. 
So basically you get all the 

367
00:21:02,500 --> 00:21:06,600
nice benefits and gradients of 
security, but you also get the 

368
00:21:06,608 --> 00:21:09,900
guarantee that you can actually 
get to scale. 

369
00:21:09,900 --> 00:21:12,400
You can get to the maximum 
amount of scale we can we can 

370
00:21:12,400 --> 00:21:17,600
get out of these systems and 
that I think is something you 

371
00:21:17,600 --> 00:21:22,200
don't get with typically VM 
systems is, have they really at 

372
00:21:22,200 --> 00:21:25,500
the design stage maximize the 
amount of processing and the 

373
00:21:25,500 --> 00:21:28,500
amount of efficiency that you 
can get out of the system? 

374
00:21:28,600 --> 00:21:31,000
And also the kinds of things you
can do with the system. 

375
00:21:31,000 --> 00:21:35,400
So I would just say for a 
project you looking to deploy 

376
00:21:35,400 --> 00:21:39,100
into Fuel and you're looking to 
deploy into kind of, this newer,

377
00:21:39,100 --> 00:21:43,500
ecosystems, newer, Paradigm of 
thinking, they'll be a few 

378
00:21:43,500 --> 00:21:47,900
different execution layers for 
you to deploy to and initially, 

379
00:21:47,900 --> 00:21:52,000
with fuel, will start with one, 
but you'll have a gradient of 

380
00:21:52,000 --> 00:21:55,100
options between price and 
security and settlement. 

381
00:21:55,100 --> 00:21:58,600
And so I think it's giving 
developers a lot more options. 

382
00:21:58,700 --> 00:22:01,700
Ins and granularity, which is 
going to be really, really 

383
00:22:01,700 --> 00:22:06,400
important versus just having 
them deployed to some layer one 

384
00:22:06,600 --> 00:22:09,700
over here or somewhere, one over
there, where effectively their 

385
00:22:09,700 --> 00:22:12,800
apps, just going to go and die 
and they're not going to have 

386
00:22:13,100 --> 00:22:16,000
the settlement or 
interoperability characteristics

387
00:22:16,000 --> 00:22:17,700
that I think they would want for
their application. 

388
00:22:18,500 --> 00:22:22,100
Yeah, absolutely. 
So maybe let's go into the into 

389
00:22:22,100 --> 00:22:27,300
the tech stack itself so fewer 
as a system has the ability to 

390
00:22:27,300 --> 00:22:30,100
kind of paralyzed Transaction 
computation. 

391
00:22:30,600 --> 00:22:32,900
How do you go about this? 
How do you make sure that you 

392
00:22:32,900 --> 00:22:37,700
don't touch on the same 
addresses in different paralyzed

393
00:22:37,700 --> 00:22:41,900
threads? 
Yeah, so I think the easiest way

394
00:22:41,900 --> 00:22:44,100
to break those down. 
It's just that when you're 

395
00:22:44,100 --> 00:22:47,200
processing transactions you 
would like to multi-thread. 

396
00:22:47,300 --> 00:22:49,000
So you'd like to process 
different chunks of 

397
00:22:49,000 --> 00:22:52,500
transactions, all the same time 
and I think this is like, a 

398
00:22:52,508 --> 00:22:56,700
really key differentiator 
benefit of systems that have 

399
00:22:56,700 --> 00:23:00,500
been redesigned or Systems like 
fuel that can do this. 

400
00:23:00,500 --> 00:23:05,600
But the core way that we achieve
it is through UT EXO's. 

401
00:23:05,600 --> 00:23:09,900
So, basically, the you txo model
is what we initially set out to 

402
00:23:09,908 --> 00:23:13,800
build with, with our first roll 
up on a theorem and what we 

403
00:23:13,800 --> 00:23:17,500
still carry through today with 
our designs and the UT Excel 

404
00:23:17,500 --> 00:23:20,700
model, just allows you to 
basically notate, okay? 

405
00:23:20,700 --> 00:23:24,200
These transactions are going to 
touch these areas of state and 

406
00:23:24,700 --> 00:23:27,300
you can just statically analyze 
the blocks beforehand and you 

407
00:23:27,300 --> 00:23:31,000
can parallel process them. 
So, this is something that has 

408
00:23:31,000 --> 00:23:33,900
been a real struggle with evm, 
BAE Systems, and etherium based 

409
00:23:33,900 --> 00:23:37,700
systems. 
And I think there are ways to 

410
00:23:37,700 --> 00:23:40,900
address it, but because of the 
way, the system is architected, 

411
00:23:40,900 --> 00:23:44,600
they're still not really well 
architected for this reality. 

412
00:23:45,100 --> 00:23:48,200
And so even the benefits of 
paralyzing, something like the 

413
00:23:48,200 --> 00:23:52,100
evm are minimal versus actually 
redesigning the system to be 

414
00:23:52,100 --> 00:23:54,400
inherently designed for this 
property from the from the 

415
00:23:54,400 --> 00:23:56,600
get-go. 
I think you can see a lot more 

416
00:23:56,600 --> 00:24:00,500
scale potential. 
But yeah, the simple, the simple

417
00:24:00,500 --> 00:24:03,100
answer is that every transaction
just notates, what it's going to

418
00:24:03,100 --> 00:24:06,200
touch and state. 
And then when you get that 

419
00:24:06,200 --> 00:24:09,400
notation, you basically say, 
okay, well, we know these 

420
00:24:09,400 --> 00:24:10,600
transactions are going to touch 
this. 

421
00:24:10,600 --> 00:24:13,100
These transactions are going to 
touch that so you can break that

422
00:24:13,100 --> 00:24:15,900
up in the parallel threads in 
the parallel process it and this

423
00:24:15,900 --> 00:24:21,100
allows us to retain verification
times of the node such that you 

424
00:24:21,100 --> 00:24:23,800
know basically nodes can retain 
something like a two-week sing 

425
00:24:23,800 --> 00:24:27,200
time. 
But still process tens of 

426
00:24:27,200 --> 00:24:30,300
thousands of transactions. 
Which is very important for just

427
00:24:30,300 --> 00:24:33,800
a centralization general. 
So you want your sink times to 

428
00:24:33,800 --> 00:24:36,900
be lower. 
So yeah, that's kind of the the 

429
00:24:36,900 --> 00:24:42,300
Crux of just our system and UT X
OS allow you to accomplish that 

430
00:24:42,300 --> 00:24:45,900
by just saying, okay well you 
know every you T XO is only 

431
00:24:45,900 --> 00:24:51,100
spent once and so every time you
spend either you know some asset

432
00:24:51,100 --> 00:24:56,600
or some contract you basically 
just notate okay well I'm going 

433
00:24:56,600 --> 00:24:58,600
to spend this contract so I'm 
going to interact. 

434
00:24:58,700 --> 00:25:02,000
With it and then your notating 
things like the state 

435
00:25:02,000 --> 00:25:04,600
differentials of the block 
producers notating those. 

436
00:25:04,600 --> 00:25:07,800
And then that's it. 
It's a very simple way to 

437
00:25:07,800 --> 00:25:10,300
accomplish it and the reason why
you takes those are also 

438
00:25:10,300 --> 00:25:13,400
beneficial here versus just 
doing an account style. 

439
00:25:13,400 --> 00:25:18,100
System is that with fuel. 
We actually don't have, we don't

440
00:25:18,100 --> 00:25:20,300
have Global State routes and we 
don't have Global account 

441
00:25:20,300 --> 00:25:22,900
account routes and we don't need
to re serialize those every time

442
00:25:22,900 --> 00:25:25,200
we process things. 
So this is actually a huge 

443
00:25:25,200 --> 00:25:28,400
benefit when you get into the 
nuances of just processing. 

444
00:25:29,000 --> 00:25:31,800
Blockchains in general. 
And we can accomplish that 

445
00:25:31,800 --> 00:25:34,800
because of UT X 0s, because we 
know it's utx, OS. 

446
00:25:34,800 --> 00:25:37,900
That every you T XO cannot be 
double spend. 

447
00:25:37,900 --> 00:25:42,600
And so with these inherent 
guarantees, you can basically 

448
00:25:42,600 --> 00:25:45,500
start removing a lot of these 
big chunks of processing that we

449
00:25:45,500 --> 00:25:47,100
typically do with etherium 
nodes. 

450
00:25:47,300 --> 00:25:50,700
So there's significant 
advantages to using UT X OS 

451
00:25:50,700 --> 00:25:53,700
without any ux, downsides. 
So essentially, you can still 

452
00:25:53,700 --> 00:25:56,200
accomplish all the same things 
we do with the theory. 

453
00:25:56,200 --> 00:26:00,100
Mm, there's be no downside or 
Rachel there at all for our 

454
00:26:00,100 --> 00:26:02,600
developer it's literally all 
upside. 

455
00:26:02,800 --> 00:26:08,300
Yeah bidding like a smart 
Contracting platform on UT EXO's

456
00:26:08,600 --> 00:26:11,900
is a lot more difficult than 
doing it on an account model of 

457
00:26:11,900 --> 00:26:15,100
though, right? 
So how much do you actually have

458
00:26:15,100 --> 00:26:18,600
to what we actually have to pay 
for gaining, others upside? 

459
00:26:19,100 --> 00:26:22,900
So I would argue that, I mean if
you use fuel right now, even 

460
00:26:22,900 --> 00:26:26,500
with our other car and sdks, 
you'll notice that it's now 

461
00:26:26,500 --> 00:26:28,500
harder to use it than it is to 
use etherium it. 

462
00:26:28,700 --> 00:26:32,500
Actually oh yeah yeah Nick I'm 
not I'm not talking about that 

463
00:26:32,500 --> 00:26:34,700
the dev. 
I'm talking about the stack 

464
00:26:34,700 --> 00:26:36,500
itself. 
So basically the cool part of 

465
00:26:36,508 --> 00:26:39,800
coil, right? 
Yeah, I mean basically with UT X

466
00:26:39,800 --> 00:26:42,900
OS, you're going to pay a little
more on the data side. 

467
00:26:43,200 --> 00:26:45,500
Most likely just because you're 
notating more stuff. 

468
00:26:45,800 --> 00:26:48,100
However, if you wanted to 
accomplish parallels with exit 

469
00:26:48,100 --> 00:26:52,400
transaction execution, with a 
standard model of just metadata,

470
00:26:52,800 --> 00:26:55,400
you'd still end up paying 
similar fees anyway. 

471
00:26:56,300 --> 00:27:01,100
So the if we're talking About 
just what the downside of using 

472
00:27:01,100 --> 00:27:04,700
UT EXO's is. 
There's not many, it would 

473
00:27:04,700 --> 00:27:06,800
literally just be that there's a
little more data. 

474
00:27:07,000 --> 00:27:10,100
But again, the positive upsides 
are enormous, there's no Global 

475
00:27:10,100 --> 00:27:12,100
state tree, and no Global 
accounts fruit. 

476
00:27:12,200 --> 00:27:13,900
And these things get removed 
pretty quickly. 

477
00:27:14,400 --> 00:27:16,700
So, again, it just means that 
transactions are going to be 

478
00:27:16,700 --> 00:27:19,900
cheaper and you're going to be 
able to process a lot more of 

479
00:27:19,900 --> 00:27:22,900
them on a normal machine. 
This is that's that answer your 

480
00:27:22,900 --> 00:27:24,800
question. 
Yeah, kind of some. 

481
00:27:24,900 --> 00:27:28,000
So maybe that me, let me kind of
reframe this. 

482
00:27:28,300 --> 00:27:32,600
So, I mean, most of the 
blockchains where you txo based,

483
00:27:32,600 --> 00:27:34,700
right? 
So basically, you txo was The 

484
00:27:34,700 --> 00:27:38,500
Gnome. 
Why did you theory of opt for an

485
00:27:38,500 --> 00:27:43,200
account-based balance mother? 
And do you think if it were to 

486
00:27:43,200 --> 00:27:47,000
be redesigned today or relaunch 
day that would change? 

487
00:27:47,300 --> 00:27:52,300
Yeah, so I think the core design
behind just doing the accounts 

488
00:27:52,300 --> 00:27:54,900
model was just that it was 
simpler and it was easier to 

489
00:27:54,900 --> 00:27:59,300
reason about and manage and I 
think over time, Time, we 

490
00:27:59,300 --> 00:28:01,500
learned at least with processing
that. 

491
00:28:01,500 --> 00:28:03,900
These accounts models are 
actually pretty horrible to 

492
00:28:03,900 --> 00:28:07,300
parallel process. 
If you're continuing to Merkel 

493
00:28:07,300 --> 00:28:10,300
eyes, every single account, and 
have a root for every single 

494
00:28:10,300 --> 00:28:14,000
block. 
So, I think, the original design

495
00:28:14,000 --> 00:28:16,500
decision was just that it was 
simpler and it was easier to 

496
00:28:16,500 --> 00:28:20,700
reason about the and the thing 
is like, you know, that's a 

497
00:28:20,700 --> 00:28:23,400
totally reasonable decision to 
make at the early stages of 

498
00:28:23,400 --> 00:28:25,700
aetherium. 
However, I think given 

499
00:28:25,700 --> 00:28:32,400
everything we know now and given
how D TX home systems work and 

500
00:28:32,400 --> 00:28:34,800
how even current modern 
blockchains work. 

501
00:28:34,800 --> 00:28:38,400
So if you look at salon Des 
designer Aptos and you know so 

502
00:28:38,400 --> 00:28:42,700
we design basically we don't 
necessarily need to do it that 

503
00:28:42,700 --> 00:28:45,600
way. 
Or if you do it that way, you 

504
00:28:45,600 --> 00:28:48,800
basically lose something else 
which is you either lose like 

505
00:28:48,800 --> 00:28:53,200
clients or you lose sort of 
processing benefits that you 

506
00:28:53,200 --> 00:28:57,000
would get with UT X OS and I 
think you TX has give you really

507
00:28:57,000 --> 00:28:59,100
the best results. 
So I think it The theorem was 

508
00:28:59,100 --> 00:29:02,000
redesigned today. 
I think the huge EXL model still

509
00:29:02,000 --> 00:29:04,800
better. 
The in pretty much every way. 

510
00:29:04,900 --> 00:29:07,100
Yeah, I think they would use you
to EXO's. 

511
00:29:07,100 --> 00:29:10,100
Let's put it that way and by 
that I mean just vitalik and 

512
00:29:10,100 --> 00:29:11,000
Gavin. 
Yeah. 

513
00:29:11,900 --> 00:29:14,900
Oh, I struggled to see vitalik 
and Gavin get back together. 

514
00:29:14,900 --> 00:29:23,900
But yeah, if you would also has 
its own virtual machine that is 

515
00:29:23,900 --> 00:29:27,700
distinctly different from the 
evm, how is that? 

516
00:29:27,700 --> 00:29:33,000
So Yeah, so basically like we 
didn't with fuel, we didn't want

517
00:29:33,000 --> 00:29:38,000
to do any of this to start like 
this whole project. 

518
00:29:38,000 --> 00:29:42,300
And a lot of it has been us 
basically going through the 

519
00:29:42,300 --> 00:29:45,200
current state-of-the-art 
architectures and just kind of 

520
00:29:45,200 --> 00:29:49,000
the available architecture as we
have around us and really 

521
00:29:49,500 --> 00:29:53,100
looking at what that is and how 
that works and going okay well 

522
00:29:53,100 --> 00:29:57,700
like what do we what do we have 
available and unfortunately you 

523
00:29:57,708 --> 00:30:01,000
know going through the Away the 
evm processes, the way that 

524
00:30:01,000 --> 00:30:02,600
Solano and these other chains 
process. 

525
00:30:02,600 --> 00:30:05,400
And, and trying to look at the 
properties that we want to 

526
00:30:05,400 --> 00:30:10,200
achieve, we kind of realize that
doing our own VM would still 

527
00:30:10,200 --> 00:30:13,400
give us the absolute best 
results for the developer and 

528
00:30:13,400 --> 00:30:17,300
for blockchain in general for 
the ecosystem it would make the 

529
00:30:17,300 --> 00:30:21,300
largest contributions the 
ecosystem that we can make and 

530
00:30:21,600 --> 00:30:25,700
be most beneficial. 
And so the fuel VM is really, it

531
00:30:25,700 --> 00:30:29,000
takes lessons primarily from the
evm, but it also takes Lessons 

532
00:30:29,000 --> 00:30:33,300
from Solana, move chains, wazza 
mips and some of those other 

533
00:30:33,300 --> 00:30:36,700
architectures and basically, 
tries to give you a blockchain 

534
00:30:36,700 --> 00:30:42,500
virtual machine that is as close
as we can realize to the kind of

535
00:30:42,500 --> 00:30:46,700
best blotch, a virtual machine. 
We can design as of today and 

536
00:30:47,000 --> 00:30:50,700
the properties that we're aiming
for there are essentially, you 

537
00:30:50,700 --> 00:30:53,500
know, this physic of having to 
price every operation, that's a 

538
00:30:53,508 --> 00:30:55,800
key. 
One, another one is retaining 

539
00:30:56,200 --> 00:30:58,800
like clients, and another one is
fraud from Leti. 

540
00:30:58,800 --> 00:31:01,800
So building a virtual machine 
that's actually easy to fraud 

541
00:31:01,800 --> 00:31:03,700
prude on things. 
Like a theory of my things like 

542
00:31:03,700 --> 00:31:06,500
Solano. 
So these are actually all Key 

543
00:31:06,500 --> 00:31:09,000
Properties, some of which are 
brand-new that didn't exist 

544
00:31:09,000 --> 00:31:13,400
before that we wanted to 
incorporate into this virtual 

545
00:31:13,400 --> 00:31:18,400
machine and so inherently. 
You know, that comes with the 

546
00:31:18,400 --> 00:31:21,500
uphill battle of saying, well, 
we had to convince all these 

547
00:31:21,500 --> 00:31:24,100
steps to use it. 
However, the architecture really

548
00:31:24,100 --> 00:31:27,400
speaks for itself and I'd say 
that, devs, that use it probably

549
00:31:27,400 --> 00:31:28,500
don't want to go back to 
anything. 

550
00:31:28,600 --> 00:31:32,100
Else and as well, they can see 
that because of the way that 

551
00:31:32,100 --> 00:31:35,200
it's designed it can exist in so
many different places so it can 

552
00:31:35,200 --> 00:31:37,600
exist on different chains and 
different settings. 

553
00:31:37,600 --> 00:31:42,200
As layer to Sizzler ones, it can
really be an architecture. 

554
00:31:42,200 --> 00:31:46,300
We can use for blockchain for 
many decades from now versus 

555
00:31:46,300 --> 00:31:50,000
just trying to inch along 
existing architectures. 

556
00:31:50,000 --> 00:31:52,300
But dealing with backwards 
compatibility issues. 

557
00:31:52,900 --> 00:31:56,800
And also, you know, using other 
run times that are fine, but 

558
00:31:56,800 --> 00:31:58,700
they're not necessarily designed
for like Giants. 

559
00:31:58,700 --> 00:32:03,200
And if you try to make them like
client friendly, these designs 

560
00:32:03,200 --> 00:32:05,900
would fall apart like they would
basically lose a lot of their 

561
00:32:05,900 --> 00:32:10,300
processing benefits. 
So the designs we picked are 

562
00:32:10,300 --> 00:32:13,800
inherently for trying to give 
the blockchain community, the 

563
00:32:13,800 --> 00:32:17,700
best possible virtual machine. 
We can think of and build that 

564
00:32:17,700 --> 00:32:20,500
in a modular way that's 
extremely reusable for everyone.

565
00:32:20,600 --> 00:32:23,300
So that's kind of the the 
motivations. 

566
00:32:24,500 --> 00:32:29,200
So for a developer that like a 
solution, Developer. 

567
00:32:29,200 --> 00:32:33,900
That's used to building on evm 
or let's say a kazim, awesome 

568
00:32:33,900 --> 00:32:37,900
developer that's building on 
kazim Azam with rust. 

569
00:32:39,000 --> 00:32:42,500
What are they going to be the 
main differences for like those 

570
00:32:42,500 --> 00:32:45,700
two developer kind of 
backgrounds? 

571
00:32:45,700 --> 00:32:49,800
And what are they going to have 
to learn in order to use this 

572
00:32:49,800 --> 00:32:53,900
VM? 
Yeah, so the etherium doves will

573
00:32:53,900 --> 00:32:57,000
have the easiest time. 
Porting all their ideas over. 

574
00:32:57,100 --> 00:33:00,900
It's very similar, it works in 
very similar ways to the evm and

575
00:33:00,900 --> 00:33:04,300
we carry over a lot of the 
benefits of things like the 

576
00:33:04,300 --> 00:33:08,800
state, API or storage API. 
And some of the ways that the 

577
00:33:08,800 --> 00:33:14,900
ebm things about things to 
awasum Deb or someone running on

578
00:33:14,900 --> 00:33:17,000
like, you know, a low-level 
runtime. 

579
00:33:17,700 --> 00:33:20,300
It's basically going to be a 
little different in the sense 

580
00:33:20,300 --> 00:33:25,400
that At the VM itself has some 
key op codes for things like 

581
00:33:25,400 --> 00:33:30,300
managing fungible coins through 
YouTube, are you txo system? 

582
00:33:30,800 --> 00:33:34,400
And probably some other little 
key differences like certain 

583
00:33:34,400 --> 00:33:37,300
opcodes we've added that are 
beneficial. 

584
00:33:37,300 --> 00:33:40,300
Super beneficial for doing 
resource-constrained processing 

585
00:33:40,300 --> 00:33:43,600
which block, chains are resource
constrained but that actually 

586
00:33:43,600 --> 00:33:47,000
have huge benefits because 
they're kind of like compound 

587
00:33:47,000 --> 00:33:49,000
operations. 
So like a dynamic mem copy. 

588
00:33:49,000 --> 00:33:52,400
For example is something that 
Like ethereum desperately needs,

589
00:33:52,400 --> 00:33:56,800
and I hope eventually it will 
get, but these kinds of 

590
00:33:56,800 --> 00:34:00,900
operations are things that we've
added into the virtual machine, 

591
00:34:00,900 --> 00:34:05,100
but basically, the virtual 
machine itself, has some really 

592
00:34:05,100 --> 00:34:09,000
key differences from the VM such
as the fact that it's 64-bit, 

593
00:34:09,000 --> 00:34:13,600
not to 256, it uses registers, 
instead of Stack system, it has 

594
00:34:13,600 --> 00:34:18,000
a different memory model. 
Our call model Works in some 

595
00:34:18,000 --> 00:34:21,500
similar ways, but in other ways 
can give you Difficult benefits 

596
00:34:21,500 --> 00:34:25,400
because we have things like a 
shared Global memory context and

597
00:34:25,400 --> 00:34:29,199
so these little key differences 
end up being really, really 

598
00:34:29,199 --> 00:34:32,000
helpful. 
And you see aetherium Deb's all 

599
00:34:32,000 --> 00:34:36,400
the time trying to solve all 
these weird problems that only 

600
00:34:36,400 --> 00:34:39,699
come up because of the 
shortcomings of the evm and 

601
00:34:39,699 --> 00:34:42,199
really the right way to fix 
those things. 

602
00:34:42,199 --> 00:34:44,400
Would just be to redesign the 
system and do something 

603
00:34:44,400 --> 00:34:47,500
different and not in. 
Ignore backwards compatibility. 

604
00:34:47,900 --> 00:34:50,300
So, just from an engineering 
perspective, we get to benefit 

605
00:34:50,300 --> 00:34:52,699
from just Saying well we'll 
bring over everything. 

606
00:34:52,699 --> 00:34:54,800
We like her all these systems 
and ignore backwards 

607
00:34:54,800 --> 00:34:56,300
compatibility. 
And just give you the best 

608
00:34:56,300 --> 00:34:58,600
system we can possibly think of 
like today. 

609
00:34:59,000 --> 00:35:01,400
So that's kind of the way I 
would describe it or think about

610
00:35:01,400 --> 00:35:05,500
it. 
So you also say that you support

611
00:35:05,700 --> 00:35:09,000
multiple native assets, how is 
it different from a theorem? 

612
00:35:09,000 --> 00:35:12,800
And who what do you pay gas in 
and who determines what you pay 

613
00:35:12,800 --> 00:35:16,400
gassin? 
Yeah, so on the front of 

614
00:35:16,400 --> 00:35:19,600
multiple native assets. 
Oh so essentially our system and

615
00:35:19,600 --> 00:35:23,900
in our machine is designed 
inherently to support basically 

616
00:35:23,900 --> 00:35:28,200
treating native assets more 
assets, that people create like 

617
00:35:28,300 --> 00:35:30,100
native assets. 
So in a theory we only have one 

618
00:35:30,100 --> 00:35:34,000
native asset which is just 
either and unfortunately ethers 

619
00:35:34,000 --> 00:35:36,900
the only one that gets really 
the benefit of low-level kind of

620
00:35:36,900 --> 00:35:39,300
clients optimizations and things
like that. 

621
00:35:39,800 --> 00:35:42,900
So when you create tokens on a 
theory, we have to do them at 

622
00:35:42,900 --> 00:35:46,800
the Ation are smart contract 
level and now really hampers the

623
00:35:46,800 --> 00:35:50,200
amount of scale. 
You can create or the scale you 

624
00:35:50,200 --> 00:35:54,200
can, you can kind of access 
because you're always kind of 

625
00:35:54,200 --> 00:35:57,100
going back to the smart contract
and affecting it, State and 

626
00:35:57,100 --> 00:36:00,100
Ricci realising it and actually 
hampers a lot of the the 

627
00:36:00,100 --> 00:36:04,200
processing. 
So so on our side we basically 

628
00:36:04,200 --> 00:36:08,100
say okay well, any token can be 
a native assets or can spit out 

629
00:36:08,100 --> 00:36:13,600
this own kind of, you know, 
token that can be and live. 

630
00:36:13,700 --> 00:36:18,100
The UT exosystem and when you 
have that, it just allows you to

631
00:36:18,100 --> 00:36:22,200
do significantly more processing
over the tokens because each 

632
00:36:22,200 --> 00:36:25,400
token becomes kind of an atomic 
bundle that can go out of a 

633
00:36:25,408 --> 00:36:27,700
contract and come back into a 
contract. 

634
00:36:28,200 --> 00:36:32,400
And so, when you have that, you 
get significant processing 

635
00:36:32,400 --> 00:36:36,700
benefit, which means, just like 
way lower-cost really on the, 

636
00:36:36,700 --> 00:36:38,800
the state level, you're just 
doing one state, right? 

637
00:36:38,800 --> 00:36:41,700
And that's it. 
And again, there's no re 

638
00:36:41,700 --> 00:36:46,100
serialization and these Sorts of
things that we see with current 

639
00:36:46,100 --> 00:36:49,900
blockchains, it literally is 
just affecting one state, right?

640
00:36:50,200 --> 00:36:53,200
And so this just means cheaper 
transactions. 

641
00:36:53,600 --> 00:36:56,700
It means cheaper transactions 
for you know, whether you're 

642
00:36:56,700 --> 00:36:59,500
doing these like payments, use 
cases, or if you're just doing a

643
00:36:59,500 --> 00:37:02,800
lot of transacting in general, 
it gives you all this. 

644
00:37:02,800 --> 00:37:06,400
So massive upside and it allows 
developers to tap into the 

645
00:37:06,400 --> 00:37:09,900
native assets system. 
And there's like a huge, huge 

646
00:37:09,900 --> 00:37:12,100
benefit something that a 
theorem, really desperately 

647
00:37:12,100 --> 00:37:16,100
lacks because every toe You just
end up creating an EOC 20 and 

648
00:37:16,400 --> 00:37:18,800
unfortunately that's pretty hard
to scale when you really try to 

649
00:37:18,800 --> 00:37:22,300
get into the Crux of it. 
So as I was one side of it in 

650
00:37:22,300 --> 00:37:27,400
terms of fees, so the chains 
that will settle on ethereum 

651
00:37:28,000 --> 00:37:32,700
will all have these a neith. 
So like we're pretty Ethan Maxey

652
00:37:32,700 --> 00:37:36,500
and that sense and this Crypt 
economic reasons for this but 

653
00:37:36,500 --> 00:37:41,400
it's also just that I think for 
us like we look at Fuel and what

654
00:37:41,400 --> 00:37:45,400
fuel is as a system again To 
help scale these other systems. 

655
00:37:45,400 --> 00:37:50,000
And so you know, if we're 
deploying a you know these these

656
00:37:50,000 --> 00:37:52,800
execution lives on a theorem. 
It's like the case that eith 

657
00:37:52,800 --> 00:37:55,800
will be the the fee. 
However you will be able to have

658
00:37:55,800 --> 00:37:59,200
things like private men pools 
and be able to accept, you know,

659
00:37:59,500 --> 00:38:02,900
fees and die, or us DC, or these
sorts of things as well, 

660
00:38:02,900 --> 00:38:05,300
whatever the block producers 
want to want to accept. 

661
00:38:05,700 --> 00:38:09,400
But in general right now, are 
our current plan is just to use 

662
00:38:09,400 --> 00:38:12,900
ether as the as the fees. 
It's the learning curve for 

663
00:38:13,200 --> 00:38:18,800
like, on the like, zoso solidity
is have inspired by JavaScript 

664
00:38:18,800 --> 00:38:21,800
and right, you know what, like 
what is it, but the language 

665
00:38:21,800 --> 00:38:25,300
actually look like is it sort of
similar to solidity in this 

666
00:38:25,300 --> 00:38:29,800
sense or yeah? 
So taxed only so-so sway. 

667
00:38:29,800 --> 00:38:33,400
Our DSL really. 
Looks like it looks a lot like 

668
00:38:33,400 --> 00:38:36,000
rust so that would be the, 
that'd be the best way to 

669
00:38:36,000 --> 00:38:40,000
describe it is looking like 
rust, inherits a lot of nice 

670
00:38:40,000 --> 00:38:41,400
things from solidity and 
inherent. 

671
00:38:41,600 --> 00:38:44,900
Organize things from, you know, 
some of these are kind of 

672
00:38:44,908 --> 00:38:49,200
language that we see in space 
but the predominant inspiration 

673
00:38:49,200 --> 00:38:53,000
is still rust. 
And for Dev coming from 

674
00:38:53,600 --> 00:38:56,000
ethereum, I'd say the learning 
curve is pretty low. 

675
00:38:56,900 --> 00:38:59,500
Most literature jobs can take a 
look at Sway and learn it in 

676
00:38:59,500 --> 00:39:02,200
like a day or two. 
It's really, in fact, even a few

677
00:39:02,200 --> 00:39:07,800
hours, probably maximum because 
the language is a blockchain 

678
00:39:07,800 --> 00:39:11,300
specific language or is designed
to Target block chains. 

679
00:39:12,000 --> 00:39:15,300
It's not like learning rust off 
the bat or these other systems 

680
00:39:15,300 --> 00:39:16,500
languages. 
You're really getting a 

681
00:39:16,500 --> 00:39:19,300
language. 
That's you know very 

682
00:39:19,300 --> 00:39:22,400
familiarized with all these 
Concepts and and you know things

683
00:39:22,400 --> 00:39:23,900
that we typically do with 
blockchains. 

684
00:39:24,300 --> 00:39:28,200
So a Dev will feel very at home 
kind of using Sway and I think 

685
00:39:28,200 --> 00:39:31,700
currently we see that like most 
dads that come over especially 

686
00:39:31,700 --> 00:39:34,600
from ethereum. 
They don't want to leave and 

687
00:39:34,600 --> 00:39:37,400
even move devs, really prefer 
it. 

688
00:39:38,000 --> 00:39:41,900
So we've already started to sway
pill, bunch of move devs as And 

689
00:39:41,900 --> 00:39:47,700
then, in terms of, in terms of 
Solana and what their experience

690
00:39:47,700 --> 00:39:52,100
is like, you know, basically 
they're they're more in the rust

691
00:39:52,100 --> 00:39:54,400
category and they're using R Us 
to Target. 

692
00:39:54,400 --> 00:39:56,900
A lot of things. 
However, again using a systems 

693
00:39:56,900 --> 00:39:59,900
language to Target a blockchain,
as we've learned is a horrible 

694
00:39:59,900 --> 00:40:02,900
experience and even that goes 
for wasum as well. 

695
00:40:03,600 --> 00:40:05,500
And so, it's way. 
We really try to patch that up 

696
00:40:05,500 --> 00:40:08,300
and say, can we give developers 
an incredible. 

697
00:40:08,300 --> 00:40:11,700
So blockchain development 
experience that feels Like they 

698
00:40:11,700 --> 00:40:13,700
have full control over the 
system and feels like, the 

699
00:40:13,700 --> 00:40:17,200
compiler is really designed for 
actually targeting blockchains. 

700
00:40:17,200 --> 00:40:20,000
And in this case, specifically 
the fuel VM, but sway will also 

701
00:40:20,000 --> 00:40:22,600
be able to Target things like 
the evm in the future as well. 

702
00:40:24,100 --> 00:40:27,500
How is fuel connected to the 
etherium, with whatever the 

703
00:40:27,500 --> 00:40:32,100
second layer is. 
Yeah, so the bridge that we have

704
00:40:32,800 --> 00:40:35,600
that, we also recently released 
in beta 2, or a recent test 

705
00:40:35,600 --> 00:40:39,400
network, is some very similar to
optimism. 

706
00:40:39,400 --> 00:40:40,700
You could say. 
So there's a lot of inherited 

707
00:40:40,700 --> 00:40:43,900
properties there to optimism, 
some inspiration, from Harvard 

708
00:40:43,900 --> 00:40:47,100
from as well. 
So it's a generic like arbitrary

709
00:40:47,100 --> 00:40:50,400
message passing bridge, but you 
can basically Bridge anything 

710
00:40:50,600 --> 00:40:53,600
you can bridge at everything 
from your see 20s. 

711
00:40:53,900 --> 00:40:57,200
Seven, honey, once you can do 
all sorts of arbitrary messaging

712
00:40:57,200 --> 00:41:02,800
in and out of the system and 
basically fuel gives you full 

713
00:41:02,800 --> 00:41:05,300
settlements. 
And, you know, the properties 

714
00:41:05,300 --> 00:41:08,500
that you're looking for as a Dev
to settle on something about 

715
00:41:08,500 --> 00:41:12,400
something like ethereum, but for
any kind of token. 

716
00:41:12,400 --> 00:41:18,000
So for example, if you wanted to
create an NFC on a fuel, have it

717
00:41:18,000 --> 00:41:21,600
massively, scalable meant, 
millions of them and then have 

718
00:41:21,600 --> 00:41:24,400
some of them be able to come 
back under with your IAM settle 

719
00:41:24,700 --> 00:41:28,000
you could do that. 
You can also just take you SCC 

720
00:41:28,000 --> 00:41:32,300
and dime these other things. 
Put them over the bridge and 

721
00:41:32,308 --> 00:41:35,800
they become native Assets in the
fuel and can benefit from our UT

722
00:41:35,800 --> 00:41:39,500
access system. 
So essentially we get to fully 

723
00:41:39,500 --> 00:41:44,700
interoperate with the theorem 
liquidity and and you know, and 

724
00:41:44,700 --> 00:41:48,000
that goes for a friend of T's a 
fundable tokens so I'd be the 

725
00:41:48,008 --> 00:41:49,900
best way to describe it. 
Yeah. 

726
00:41:50,700 --> 00:41:53,100
Okay. 
And what about the notes that 

727
00:41:53,100 --> 00:41:55,900
actually run fuel? 
So who runs those? 

728
00:41:56,700 --> 00:41:58,500
Yeah. 
So, currently we're starting out

729
00:41:58,508 --> 00:42:00,100
with a single sequencer or 
model. 

730
00:42:00,100 --> 00:42:04,200
So, similar to arbitrament 
optimism, with some, some 

731
00:42:04,200 --> 00:42:07,300
fallbacks, that's mainly just to
get everything set up and to 

732
00:42:07,300 --> 00:42:11,200
allow Deb's to actually get to 
production after that point, 

733
00:42:11,200 --> 00:42:15,400
though we will actually look to 
decentralize block production. 

734
00:42:15,500 --> 00:42:20,700
And this is like, a key piece of
architecture and The 

735
00:42:20,700 --> 00:42:23,800
centralizing block production, 
what we mean is is being able to

736
00:42:23,800 --> 00:42:27,000
have many different block. 
Producers not a single sequencer

737
00:42:27,500 --> 00:42:31,600
but you still get to benefit 
from all of the nice upsides of 

738
00:42:31,600 --> 00:42:33,600
things like layer 2 is an 
optimistic Roll-Ups. 

739
00:42:34,500 --> 00:42:37,000
So you get a essentially like a 
decentralized sequencer, you 

740
00:42:37,000 --> 00:42:41,700
could say and the way that we 
accomplished that is really 

741
00:42:41,700 --> 00:42:45,600
through a tenement like system. 
However you get all the upsides 

742
00:42:45,600 --> 00:42:48,400
of tenement and not the 
downsides which is that the 

743
00:42:48,400 --> 00:42:52,000
security of the system is 
typically taken care of by a 

744
00:42:52,000 --> 00:42:55,100
theorem itself and data 
availability, being secure and 

745
00:42:55,100 --> 00:42:57,600
on something like a theorem or 
something like Celeste yet. 

746
00:42:57,700 --> 00:43:02,200
So you basically get to do 
everything, you really want with

747
00:43:02,200 --> 00:43:04,100
a blockchain, you get to have 
all the nice properties that 

748
00:43:04,100 --> 00:43:08,700
you're looking for and you don't
really have very many downsides 

749
00:43:08,700 --> 00:43:11,000
so that's that's kind of where 
we're headed with that. 

750
00:43:12,600 --> 00:43:15,700
I want to take a step back a 
little bit here and we were 

751
00:43:15,700 --> 00:43:18,100
talking about bridging just 
briefest previously here. 

752
00:43:18,800 --> 00:43:25,400
What does bridging look like in 
a modular stack ecosystem or 

753
00:43:25,900 --> 00:43:31,200
application, it does bridging 
happen at the application layer 

754
00:43:31,200 --> 00:43:34,800
at the execution layer or does 
it happen at lower layers in the

755
00:43:34,800 --> 00:43:39,600
stack and the other question I 
have is you know more broadly. 

756
00:43:40,100 --> 00:43:43,700
I think that one of the biggest 
challenges Is right now is 

757
00:43:44,300 --> 00:43:48,800
creating trustless or trust 
minimize bridging standards 

758
00:43:48,800 --> 00:43:54,500
across different ecosystems. 
So the etherium evm ecosystem 

759
00:43:54,600 --> 00:44:01,100
has solutions for bridging 
across evm chains polka dot has 

760
00:44:01,100 --> 00:44:04,600
also their own protocol Cosmos 
as their own protocol. 

761
00:44:04,600 --> 00:44:06,700
I'm not quite sure what's 
happening sort of like in Solana

762
00:44:06,700 --> 00:44:08,600
and other ecosystems. 
I think probably Avalanche also 

763
00:44:08,600 --> 00:44:11,900
has like I think they do have a 
bridging protocol that leverages

764
00:44:12,200 --> 00:44:17,900
he is GX you know as as these 
chains become more modular and 

765
00:44:18,000 --> 00:44:21,800
you know some abusing the evm 
execution and others might be 

766
00:44:21,800 --> 00:44:25,500
using like Waze mm but they're 
all using that the they're all 

767
00:44:25,500 --> 00:44:28,200
sharing data availability and 
maybe sharing consensus or 

768
00:44:28,200 --> 00:44:31,600
sharing some other layer. 
How do we reason about creating 

769
00:44:31,600 --> 00:44:33,600
standards here? 
That allows these chains that 

770
00:44:33,600 --> 00:44:36,500
were operated does the modulo 
stack facilitate this 

771
00:44:36,500 --> 00:44:40,800
interoperability Yeah, so I 
think with bridging, you have, 

772
00:44:41,300 --> 00:44:44,100
you have a few different kinds 
of bridging here. 

773
00:44:44,100 --> 00:44:48,600
So one being just bridging that,
you know, we typically see with 

774
00:44:48,600 --> 00:44:51,000
just having an execution, like a
bridge to something like a 

775
00:44:51,008 --> 00:44:53,300
theory. 
I'm so, you know, a bridge that 

776
00:44:53,500 --> 00:44:56,000
we've seen with, you know, 
Arbiter more optimism, that kind

777
00:44:56,000 --> 00:45:00,600
of setup and those bridges are 
more about, I would say 

778
00:45:00,600 --> 00:45:04,100
settlement and as well, we use 
them for different aspects of 

779
00:45:04,100 --> 00:45:06,300
like block production and 
posting headers and things like 

780
00:45:06,300 --> 00:45:09,200
that. 
Other Bridges though. 

781
00:45:09,200 --> 00:45:14,700
That you want, you want some Key
Properties, if you really want 

782
00:45:14,700 --> 00:45:17,900
to achieve trust minimize 
bridging, so some nice 

783
00:45:17,900 --> 00:45:21,600
properties that you get with 
modular block chains, or with 

784
00:45:21,600 --> 00:45:24,500
blockchains or execution lies 
that share the same data 

785
00:45:24,500 --> 00:45:28,800
availability, is that each 
execution layer can introspect 

786
00:45:28,800 --> 00:45:31,200
each other. 
So, basically, you can 

787
00:45:31,200 --> 00:45:35,900
introspect from one layer. 
You can say, what is the headers

788
00:45:35,900 --> 00:45:39,400
and the state of the said 
earlier, And if you can do that,

789
00:45:39,400 --> 00:45:41,800
you can create these trust 
minimize Bridges. 

790
00:45:41,800 --> 00:45:45,100
Where essentially set up having 
like a multi sitting on both 

791
00:45:45,100 --> 00:45:49,400
sides, you can actually have two
smart contracts on both sides of

792
00:45:49,400 --> 00:45:52,500
the bridge. 
And so let's say you were 

793
00:45:52,500 --> 00:45:56,300
bridging from one fuel instance 
to another fuel incense on 

794
00:45:56,300 --> 00:46:00,200
aetherium because both of these 
layers have the same date 

795
00:46:00,200 --> 00:46:06,600
availability and they have the 
same you know, headers or they 

796
00:46:06,600 --> 00:46:11,800
have any easy to Respect 
Blockhead our system, you can 

797
00:46:11,800 --> 00:46:14,000
basically create a trust 
minimize bridge between the two 

798
00:46:14,000 --> 00:46:17,500
of them. 
And it's trust minimized because

799
00:46:17,600 --> 00:46:21,100
you're not really relying on 
necessarily things like multi 6 

800
00:46:21,300 --> 00:46:25,100
on both sides. 
And so this gives you some huge 

801
00:46:25,100 --> 00:46:27,500
benefits when you're actually 
moving and bridging liquidity 

802
00:46:27,700 --> 00:46:32,300
between these execution systems 
so that would be one way to 

803
00:46:32,300 --> 00:46:34,100
describe it. 
If you're building execution 

804
00:46:34,100 --> 00:46:36,500
systems on on Celestial would be
the same. 

805
00:46:36,500 --> 00:46:42,200
So you know, You basically, you 
share data availability and so, 

806
00:46:42,200 --> 00:46:44,900
you know, one executioner can 
actually introspect the other 

807
00:46:45,600 --> 00:46:48,900
and that's like a very key 
property with trust minimize 

808
00:46:48,900 --> 00:46:52,700
bridges. 
That I think will be a huge game

809
00:46:52,700 --> 00:46:55,700
changing set of factor for why 
you would want to pick a modular

810
00:46:55,700 --> 00:46:59,100
Block Chain versus just picking 
these layer ones, because we've 

811
00:46:59,100 --> 00:47:01,900
already seen so many bridges 
fail with, multi, cigs that 

812
00:47:02,200 --> 00:47:05,200
really? 
If we're going to continue to 

813
00:47:05,200 --> 00:47:08,500
build newer, blockchains you're 
going to want these He's in your

814
00:47:08,500 --> 00:47:10,800
block chains, so that you can 
actually enter operate. 

815
00:47:10,800 --> 00:47:14,600
All the liquidity, it also works
well for upgradability when 

816
00:47:14,600 --> 00:47:16,900
you're doing a new execution. 
Learn you want to move things 

817
00:47:16,900 --> 00:47:20,400
over? 
You can also you know, move you 

818
00:47:20,400 --> 00:47:21,700
can introspect the previous 
state. 

819
00:47:21,700 --> 00:47:23,800
You can also move assets and 
liquidity over. 

820
00:47:23,800 --> 00:47:28,500
So some really Key Properties 
there that are really nice for 

821
00:47:28,500 --> 00:47:31,300
change that are applications 
that are using different data. 

822
00:47:31,300 --> 00:47:33,400
Availability Lera. 
They I guess like that's kind of

823
00:47:33,408 --> 00:47:35,200
like the bottom layer in the 
stack. 

824
00:47:35,200 --> 00:47:38,700
Are we going to need like 
interoperability Between data 

825
00:47:38,700 --> 00:47:41,800
availability like you know 
aetherium data availability and 

826
00:47:41,800 --> 00:47:44,500
Celestia and I don't know like 
what other data availability 

827
00:47:44,500 --> 00:47:47,300
there. 
Is that really where like if 

828
00:47:47,300 --> 00:47:49,900
change certain if the ecosystem 
starts moving towards is more 

829
00:47:49,900 --> 00:47:52,600
modular stack. 
And there are kind of data 

830
00:47:52,600 --> 00:47:57,800
availability monoliths. 
Are we going to need to have 

831
00:47:57,800 --> 00:47:59,700
like some bridging between these
data? 

832
00:47:59,700 --> 00:48:02,800
Availability layers are, can 
they validate each other? 

833
00:48:03,600 --> 00:48:06,500
Yeah, I mean, ideally, you would
want them to interoperate but 

834
00:48:06,500 --> 00:48:09,300
then you have basically Actually
different different layer ones 

835
00:48:09,300 --> 00:48:10,700
trying to interoperate with each
other. 

836
00:48:10,700 --> 00:48:14,300
So you're still going to inherit
the same sort of fill failure, 

837
00:48:14,300 --> 00:48:18,000
properties of sort of typical 
Bridges between their ones. 

838
00:48:18,000 --> 00:48:22,100
So I would say that the real 
benefit comes from bridging 

839
00:48:22,100 --> 00:48:26,500
between execution layers on the 
same layer, one is going to be 

840
00:48:26,900 --> 00:48:29,600
the best possible thing you can 
do. 

841
00:48:29,600 --> 00:48:34,300
So like, if systems, like 
arbitrament autism actually had 

842
00:48:34,300 --> 00:48:36,800
better to centralize sequencing,
then you could, you could have a

843
00:48:36,800 --> 00:48:40,200
lot of nice guarantee. 
He's between bridging between 

844
00:48:40,500 --> 00:48:43,500
those execution, errors, 
insulin-like fuel if it was 

845
00:48:43,500 --> 00:48:48,000
deployed tomorrow on ethereum 
because etherium would be the 

846
00:48:48,000 --> 00:48:51,000
shared data availability and 
execution are you know in that 

847
00:48:51,000 --> 00:48:54,800
in that case and so I would just
say that. 

848
00:48:55,300 --> 00:49:01,300
Yeah, you still have the same 
failure points if the if 

849
00:49:01,300 --> 00:49:03,400
essentially they are there 
separate layer ones. 

850
00:49:03,400 --> 00:49:08,000
Yeah, so still the same problem.
How does this translate into 

851
00:49:08,000 --> 00:49:11,100
ecosystem? 
So there's currently only a test

852
00:49:11,100 --> 00:49:14,500
net out but who are the people 
building on fuel. 

853
00:49:15,300 --> 00:49:17,200
Yeah. 
So right now I'd say we have 

854
00:49:17,200 --> 00:49:21,000
like a small kind of following a
projects, our current philosophy

855
00:49:21,000 --> 00:49:24,700
with fuel is that we really 
don't need thousands of projects

856
00:49:24,700 --> 00:49:27,100
to build our own fuel. 
We need only like ten good ones.

857
00:49:27,200 --> 00:49:32,500
So for us like we don't care 
about having 500 and ft rug pull

858
00:49:32,500 --> 00:49:35,500
projects on our system. 
It's not really anything we 

859
00:49:35,800 --> 00:49:37,700
need. 
Care about or that benefits 

860
00:49:37,700 --> 00:49:41,500
anybody the projects that we 
currently have building on fuel.

861
00:49:41,500 --> 00:49:45,400
We've huge axis. 
A few nft systems and then a few

862
00:49:45,800 --> 00:49:50,700
Landing systems. 
And I would say that the key 

863
00:49:50,700 --> 00:49:53,500
differentiating things about 
them are going to be that they 

864
00:49:53,500 --> 00:49:57,000
can leverage sort of things 
like, feels account abstraction 

865
00:49:57,400 --> 00:49:59,600
or they can leverage like 
paralyzation. 

866
00:50:00,200 --> 00:50:02,800
They can leverage some unique 
properties of other fuel VM or 

867
00:50:02,800 --> 00:50:06,300
about sway about having a 
significantly larger. 

868
00:50:06,400 --> 00:50:11,600
ER amount of memory available at
computation time and just like 

869
00:50:12,000 --> 00:50:15,300
all these little key details 
will allow them to create a 

870
00:50:15,300 --> 00:50:20,100
highly differentiated product 
from or system than what you 

871
00:50:20,100 --> 00:50:23,600
typically see with evm systems. 
But it'll still be accessible to

872
00:50:23,600 --> 00:50:26,200
people with things like meta, 
Mass wallets, and ethereum 

873
00:50:26,200 --> 00:50:28,300
volume. 
So that's really the best part 

874
00:50:28,300 --> 00:50:31,900
is the accessibility is still 
with etherium and all that sort 

875
00:50:31,900 --> 00:50:34,000
of stuff. 
It's just all that underlying 

876
00:50:34,000 --> 00:50:35,800
architecture allows you to do 
way more. 

877
00:50:36,400 --> 00:50:39,900
So that would be the way that I 
would describe it. 

878
00:50:40,400 --> 00:50:44,600
Like some some notable names are
like Helix and pool sharks and 

879
00:50:45,300 --> 00:50:48,100
and eunuch as well. 
And I'd say a lot of the 

880
00:50:48,100 --> 00:50:52,200
projects that are building on 
fuel are far more ideologically 

881
00:50:52,200 --> 00:50:55,900
or philosophically aligns to I 
think the values of building, 

882
00:50:55,900 --> 00:50:58,900
these kinds of centralized 
systems, and building something 

883
00:50:58,900 --> 00:51:02,900
that is actually fundamentally 
unique and not something that is

884
00:51:02,900 --> 00:51:05,600
just going to be another like I 
don't know. 

885
00:51:05,800 --> 00:51:10,700
I just another project or a 
copycat project quiz, so what's 

886
00:51:10,700 --> 00:51:15,100
the roadmap look like? 
So when Maynard sort of hesitant

887
00:51:15,100 --> 00:51:20,100
to give a date from a net but 
I'll preliminarily say that 

888
00:51:20,700 --> 00:51:23,200
there's two tests Nets until 
something will happen. 

889
00:51:24,300 --> 00:51:27,100
So we just need to do about two 
more tests nuts. 

890
00:51:27,100 --> 00:51:31,700
And then I would say that we're 
in a pretty good space to be 

891
00:51:31,700 --> 00:51:36,700
actually going to go into the 
net and You know, I would say 

892
00:51:36,800 --> 00:51:39,100
it'll be probably another two 
quarters, something like that, 

893
00:51:39,700 --> 00:51:44,700
if I were to guess but that that
would be my my somewhat Alpha 

894
00:51:44,700 --> 00:51:48,100
drop there. 
However, I will say that with 

895
00:51:48,800 --> 00:51:51,900
fuel itself like everything you 
would want to build, you can 

896
00:51:51,900 --> 00:51:54,900
build right now over the test. 
That's so everything still being

897
00:51:54,900 --> 00:51:58,400
kind of scaffold and put 
together but you can basically 

898
00:51:58,400 --> 00:52:00,500
build anything that you would 
want right now. 

899
00:52:00,500 --> 00:52:04,700
Anyway, so don't hesitate to 
actually start. 

900
00:52:04,900 --> 00:52:07,100
Getting fuel building stuff with
it. 

901
00:52:07,200 --> 00:52:12,100
Yeah, if you're a project. 
So where can people come and 

902
00:52:12,100 --> 00:52:14,200
find out more about Fuel and get
started? 

903
00:52:14,700 --> 00:52:17,200
Yeah, so you can just start with
fuel dot Network. 

904
00:52:17,200 --> 00:52:19,900
So everything is available 
through that. 

905
00:52:20,500 --> 00:52:22,100
That's where you can find all of
our dogs. 

906
00:52:23,000 --> 00:52:28,500
And basically, we got a ton of 
like great tutorials guides, 

907
00:52:28,500 --> 00:52:31,100
Etc. 
We're always looking to improve 

908
00:52:31,100 --> 00:52:33,200
the docks. 
So that's like an ongoing thing 

909
00:52:33,200 --> 00:52:35,600
just get your ducks. 
Excellent. 

910
00:52:35,600 --> 00:52:38,400
I went through the last night 
and they, yeah, they accident. 

911
00:52:38,400 --> 00:52:41,900
I took, I took several notes for
our own dogs, so amazing. 

912
00:52:42,200 --> 00:52:45,000
Yeah, I mean, we still, there's 
still even more we can do. 

913
00:52:45,000 --> 00:52:48,900
So it's what will continue to 
increase the the docks, and as 

914
00:52:48,900 --> 00:52:51,300
well, just everything across the
board. 

915
00:52:51,300 --> 00:52:54,300
So, we're in taking as much 
feedback as we can from devs. 

916
00:52:54,300 --> 00:52:58,400
Because we have a unique 
opportunity here to build a 

917
00:52:58,400 --> 00:53:00,400
system that I think Deb's 
actually would really like to 

918
00:53:00,400 --> 00:53:02,900
use and that gives them 
everything they need. 

919
00:53:03,000 --> 00:53:06,100
So like that. 
That's going to be very key for 

920
00:53:06,100 --> 00:53:09,100
us and it allows us to 
differentiate in a big way from 

921
00:53:09,200 --> 00:53:11,900
existing tool chains that have 
had to sort of learn the hard 

922
00:53:11,900 --> 00:53:15,400
way how to build a lot of the 
stuff so Bluefin Hasek. 

923
00:53:15,600 --> 00:53:18,700
I'm excited to see how this 
would go and how long, the two 

924
00:53:18,700 --> 00:53:21,400
tests Nets will take and to see 
this in action. 

925
00:53:22,000 --> 00:53:26,800
Awesome, thank you, Nick. 
Thank you for joining us on this

926
00:53:26,800 --> 00:53:29,200
week's episode. 
We release new episodes every 

927
00:53:29,200 --> 00:53:31,200
week. 
You can find And subscribe to 

928
00:53:31,200 --> 00:53:35,000
the show on iTunes Spotify, 
YouTube SoundCloud or wherever 

929
00:53:35,000 --> 00:53:37,400
you listen to podcast. 
And if you have a Google home or

930
00:53:37,400 --> 00:53:40,100
Alexa device, you can tell it to
listen to the latest episode of 

931
00:53:40,107 --> 00:53:44,100
the epicenter podcast, go to 
epicenter, .t V /, subscribe for

932
00:53:44,100 --> 00:53:46,700
a full list of places where you 
can watch and listen, while 

933
00:53:46,700 --> 00:53:49,000
you're there, be sure to sign up
for the newsletter so you get 

934
00:53:49,000 --> 00:53:52,400
new episodes in your inbox as 
the released if you want to 

935
00:53:52,400 --> 00:53:54,000
interact with us guests or 
other. 

936
00:53:54,100 --> 00:53:56,900
Podcast listeners, you can 
follow us on Twitter and please 

937
00:53:56,900 --> 00:53:59,300
leave us a review on iTunes. 
It helps people find the show 

938
00:53:59,500 --> 00:54:02,700
and we're always happy to read 
them, but thanks so much and we 

939
00:54:02,700 --> 00:54:04,100
look forward to being back next 
week. 

940
00:53:54,100 --> 00:53:56,900
Podcast listeners, you can 
follow us on Twitter and please 

941
00:53:56,900 --> 00:53:59,300
leave us a review on iTunes. 
It helps people find the show 

942
00:53:59,500 --> 00:54:02,700
and we're always happy to read 
them, but thanks so much and we 

943
00:54:02,700 --> 00:54:04,100
look forward to being back next 
week.