1
00:00:00,040 --> 00:00:03,400
When we first started Polymer, 
the interoperability landscape 

2
00:00:03,400 --> 00:00:06,520
was very different. 
I think the thesis then was 

3
00:00:06,880 --> 00:00:09,840
there's going to be potentially 
millions of L ones and millions 

4
00:00:09,840 --> 00:00:13,320
of these app chains. 
What we started to see was the 

5
00:00:13,320 --> 00:00:17,080
landscape began to shift and we 
started to see this rise in the 

6
00:00:17,080 --> 00:00:19,360
number of layer twos and not 
just layer twos. 

7
00:00:19,360 --> 00:00:21,680
Originally, these layer twos 
were just individual layer twos,

8
00:00:21,680 --> 00:00:23,440
but they've changed into layer 2
frameworks. 

9
00:00:23,760 --> 00:00:27,080
We retained what we called 
virtual IBC just enabled us to 

10
00:00:27,080 --> 00:00:30,640
permissionlessly expand the IPC 
network, but we shifted the 

11
00:00:30,680 --> 00:00:34,160
underlying architecture from 
using common BFT as a layer 1 

12
00:00:34,560 --> 00:00:38,400
using the OP stack for 
settlement and chain derivation 

13
00:00:38,480 --> 00:00:42,000
from Etherium. 
What this allows is that for 

14
00:00:42,000 --> 00:00:46,040
Etherium roll ups that implement
the EIP 4788 standard, where 

15
00:00:46,040 --> 00:00:49,560
there is some layer one 
information on that pull up that

16
00:00:49,560 --> 00:00:53,080
we can utilize, we can allow 
those roll ups to communicate 

17
00:00:53,080 --> 00:00:55,560
essentially as close to block 
time as possible. 

18
00:00:56,120 --> 00:00:58,000
Welcome to Epicenter, the show 
which talks about the 

19
00:00:58,000 --> 00:01:00,680
technologies, projects and 
people driving decentralization 

20
00:01:00,680 --> 00:01:03,880
and the blockchain revolution. 
I'm Sebastne Quito and today I'm

21
00:01:03,880 --> 00:01:06,960
speaking with Bo Dew, who's Co 
founder and CTO at Polymer. 

22
00:01:07,160 --> 00:01:09,240
They're building an 
interoperability hub for 

23
00:01:09,240 --> 00:01:11,760
Ethereum. 
Before I start with Bo, here's 

24
00:01:11,760 --> 00:01:13,440
some information about our 
sponsors this week. 

25
00:01:14,720 --> 00:01:18,560
Cars 1 is one of the biggest 
node operators globally and help

26
00:01:18,560 --> 00:01:22,680
you stake your tokens on 45 plus
networks like Ethereum, Cosmos, 

27
00:01:23,080 --> 00:01:27,560
Celestia, and DYDX. 
More than 100,000 delegators 

28
00:01:27,560 --> 00:01:31,080
stake with Chorus One, including
institutions like Bid Go and 

29
00:01:31,080 --> 00:01:33,880
Ledger. 
Staking with Chorus 1 not only 

30
00:01:33,880 --> 00:01:38,560
gets you the highest years but 
also the most robust security 

31
00:01:38,560 --> 00:01:41,720
practices in infrastructure that
are usually exclusive for 

32
00:01:41,720 --> 00:01:44,760
institutions. 
You can stake directly to Chorus

33
00:01:44,760 --> 00:01:47,760
1's public note from your 
wallet, set up a white table 

34
00:01:47,760 --> 00:01:51,760
note, or use the recently 
launched product Opus to stake 

35
00:01:51,760 --> 00:01:54,560
up to 8000 ETH in a single 
transaction. 

36
00:01:55,320 --> 00:01:59,000
You can even offer high yield 
staking to your own customers 

37
00:01:59,240 --> 00:02:02,000
using their API. 
Your assets always remain in 

38
00:02:02,000 --> 00:02:04,600
your custody, so you can have 
complete Peace of Mind. 

39
00:02:04,800 --> 00:02:07,720
Start staking today at Chorus 
.1. 

40
00:02:08,960 --> 00:02:12,200
This episode is proudly brought 
to you by Gnosis, a collective 

41
00:02:12,200 --> 00:02:14,680
dedicated to advancing a 
decentralized future. 

42
00:02:15,200 --> 00:02:19,400
Nosys leads innovation with 
Circles, Nosys Pay and Metri, 

43
00:02:19,480 --> 00:02:21,680
reshaping open banking and 
money. 

44
00:02:22,040 --> 00:02:25,120
With Hashi and Nosys VPN, 
they're building a more 

45
00:02:25,120 --> 00:02:27,600
resilient, privacy focused 
Internet. 

46
00:02:28,040 --> 00:02:31,800
If you're looking for an L1 to 
launch your project, Nosys Chain

47
00:02:31,800 --> 00:02:35,160
offers the same development 
environment as Aetherium with 

48
00:02:35,160 --> 00:02:39,240
lower transaction fees. 
It's supported by over 200,000 

49
00:02:39,240 --> 00:02:43,080
validators, making Nosys Chain a
reliable and credibly neutral 

50
00:02:43,080 --> 00:02:44,600
foundation for your 
applications. 

51
00:02:45,080 --> 00:02:48,920
Gnosis Dow drives Gnosis 
governance, where every voice 

52
00:02:48,920 --> 00:02:51,600
matters. 
Join the Gnosis community in the

53
00:02:51,600 --> 00:02:56,040
Gnosis Dow forum today. 
Deploy on the EVM compatible 

54
00:02:56,040 --> 00:03:01,160
Gnosis Chain or secure the 
network with just one GNO and 

55
00:03:01,160 --> 00:03:04,160
affordable hardware. 
Start your decentralization 

56
00:03:04,160 --> 00:03:08,080
journey today at gnosis dot IO. 
Hey, Bo, thanks for coming on 

57
00:03:08,080 --> 00:03:10,240
this week. 
Yeah, thanks for having me. 

58
00:03:11,680 --> 00:03:13,680
Yeah, so we were talking about 
before the show, so actually 

59
00:03:13,680 --> 00:03:16,240
you've been on my podcast, the 
Interop, a couple of times, but 

60
00:03:16,240 --> 00:03:18,440
this is your first time on 
Epicenter, so, you know, we'll 

61
00:03:18,440 --> 00:03:22,680
have to set aside all of those 
interesting conversations and, 

62
00:03:22,840 --> 00:03:25,200
you know, maybe start from a 
high level here. 

63
00:03:25,600 --> 00:03:27,600
But yeah, how's your summer 
going? 

64
00:03:28,400 --> 00:03:32,360
It's pretty good gearing up for 
for main net soon. 

65
00:03:33,800 --> 00:03:35,520
We're working hard, going to a 
lot of these different 

66
00:03:35,520 --> 00:03:37,840
conferences and and trying to 
talk about what we're doing. 

67
00:03:39,400 --> 00:03:42,640
Yeah, it's exciting and you 
know, it's it's been it's been a

68
00:03:42,640 --> 00:03:44,560
long time coming. 
You guys have been working on 

69
00:03:44,560 --> 00:03:47,360
Polymer for some time. 
In fact, I first heard about you

70
00:03:47,360 --> 00:03:50,760
guys two years ago. 
Just disclaimer here, I'm an 

71
00:03:50,760 --> 00:03:54,400
Angel investor in Polymer. 
But with that out of the way, I 

72
00:03:54,400 --> 00:03:58,040
think we can have a conversation
about the technology, about the 

73
00:03:58,040 --> 00:04:02,160
Polymer hub and the SDK that you
guys are building. 

74
00:04:02,160 --> 00:04:08,440
And and also, you know, your 
fervent, I guess that defense 

75
00:04:08,440 --> 00:04:12,080
and and love of IBC, you know, 
as like the standard for 

76
00:04:12,080 --> 00:04:15,720
interruptability in crypto, 
which I tend to agree with. 

77
00:04:15,840 --> 00:04:18,839
And I think, you know, you sort 
of like speech, speaking to the 

78
00:04:18,839 --> 00:04:23,240
choir, preaching to the choir 
here on Epicenter, at least, you

79
00:04:23,240 --> 00:04:26,400
know, as a lot of folks here are
like familiar with Cosmos and 

80
00:04:26,400 --> 00:04:28,680
familiar with IBC. 
So yeah, maybe a little bit of 

81
00:04:28,680 --> 00:04:30,920
background on Palmer and like 
how you guys got here. 

82
00:04:31,600 --> 00:04:34,680
Yeah, absolutely. 
I can do it quick. 

83
00:04:35,000 --> 00:04:38,400
I guess self background of 
myself for the folks that are 

84
00:04:38,400 --> 00:04:40,600
that are new, that haven't heard
me talk before. 

85
00:04:41,160 --> 00:04:43,760
So my name is Bo, I'm a 
technical Co founder at Polymer.

86
00:04:44,720 --> 00:04:47,960
My personal background has 
mostly been in Web 2, worked at 

87
00:04:47,960 --> 00:04:49,720
a bunch of different start-ups, 
worked at Uber. 

88
00:04:50,440 --> 00:04:53,320
I worked in a small startup 
called Chronosphere which became

89
00:04:53,320 --> 00:04:56,600
quite bit quite large. 
Switched over to working in D5 

90
00:04:56,600 --> 00:04:59,280
for a period of time and 
ultimately ended up switching to

91
00:04:59,280 --> 00:05:01,760
Interop. 
I would say that when we first 

92
00:05:01,760 --> 00:05:04,680
started Polymer, the 
interoperability landscape was 

93
00:05:04,680 --> 00:05:07,720
very different. 
I think the thesis then was 

94
00:05:08,080 --> 00:05:11,040
there's going to be potentially 
millions of L ones and millions 

95
00:05:11,040 --> 00:05:15,200
of these app chains, maybe a few
large L ones and I guess the law

96
00:05:15,200 --> 00:05:19,880
until these like L1 app chains 
and that world has changed a 

97
00:05:19,880 --> 00:05:22,720
bit. 
So our initial product was 

98
00:05:22,760 --> 00:05:26,280
focused on on that we were 
building an L1. 

99
00:05:26,560 --> 00:05:29,040
We wanted to connect all these 
different, different L ones, 

100
00:05:29,800 --> 00:05:31,840
starting with different 
ecosystems like Ethereum. 

101
00:05:32,520 --> 00:05:36,160
We were investigating ZK, we're 
investigating all of these 

102
00:05:36,240 --> 00:05:39,480
different technologies because 
we wanted to make it cost 

103
00:05:39,480 --> 00:05:43,680
efficient to connect securely 
from like a cosmos chain to 

104
00:05:43,680 --> 00:05:46,320
Etherium. 
But as we're working on this 

105
00:05:46,320 --> 00:05:48,560
problem and as and as we had 
developed some of these like 

106
00:05:48,560 --> 00:05:52,360
proof of concept technologies to
enable this, what we started to 

107
00:05:52,360 --> 00:05:55,120
see was the landscape began to 
shift. 

108
00:05:55,600 --> 00:05:59,600
So instead of this like L1 
thesis playing out, it kind of 

109
00:05:59,800 --> 00:06:02,480
you kind of saw this like rise 
in and fall of interest in the 

110
00:06:02,480 --> 00:06:04,600
cosmos. 
I think it kind of rose with 

111
00:06:04,600 --> 00:06:07,080
Terra. 
And then after Terra and FDX and

112
00:06:07,080 --> 00:06:10,920
like the, the, the bear market 
kicked in, interest started to 

113
00:06:10,960 --> 00:06:14,560
die down a little bit and you 
started to see this rise in the 

114
00:06:14,560 --> 00:06:16,800
number of layer twos and not 
just layer twos. 

115
00:06:16,800 --> 00:06:19,160
Originally these layer twos were
just individual layer twos, but 

116
00:06:19,160 --> 00:06:20,960
they'd change into layer 2 
frameworks. 

117
00:06:21,400 --> 00:06:25,040
And this concept of roll up as a
server became really popular. 

118
00:06:25,360 --> 00:06:29,440
And I've seen a number of folks 
tweet that and mention that in 

119
00:06:29,440 --> 00:06:32,680
different talks. 
And it kind of makes sense. 

120
00:06:33,640 --> 00:06:35,560
When you have a layer one 
blockchain, you're paying for 

121
00:06:35,560 --> 00:06:40,080
consensus, you're paying for 
these things, which comes at a 

122
00:06:40,080 --> 00:06:42,640
cost in order to have 
decentralized trust. 

123
00:06:43,600 --> 00:06:46,880
But with these like layer 2 
systems, you can essentially run

124
00:06:47,240 --> 00:06:49,840
it in a fairly centralized 
fashion to get some of those 

125
00:06:49,840 --> 00:06:51,480
blockchain properties from the 
layer one. 

126
00:06:52,200 --> 00:06:55,760
And that that seems like a more 
pragmatic scaling model in terms

127
00:06:55,760 --> 00:06:59,920
of cost and efficiency. 
So our thesis changed from, OK, 

128
00:06:59,920 --> 00:07:02,720
there's going to be from 
millions of layer ones to we 

129
00:07:02,720 --> 00:07:04,440
want to connect millions of 
layer twos. 

130
00:07:05,080 --> 00:07:08,200
And because the thesis changed, 
we also had to change our focus.

131
00:07:08,720 --> 00:07:11,960
We realized that building this 
layer one solution wouldn't be 

132
00:07:11,960 --> 00:07:15,320
effective in connecting to the 
different layer 2's, the 

133
00:07:15,320 --> 00:07:18,240
technical nuance of which, you 
know, we can get into a little 

134
00:07:18,240 --> 00:07:21,200
bit later in this call. 
But I would say that it revolves

135
00:07:21,200 --> 00:07:24,680
around the latency, cost, 
safety, and all these other 

136
00:07:24,680 --> 00:07:27,440
properties. 
For us to make the best solution

137
00:07:27,440 --> 00:07:30,800
for layer twos, we realized we 
had to pivot to being a layer 2 

138
00:07:30,800 --> 00:07:34,640
ourselves. 
So we we architected the polymer

139
00:07:34,640 --> 00:07:36,360
solution. 
We did not change the 

140
00:07:37,520 --> 00:07:39,440
application layer protocol that 
we had built. 

141
00:07:40,400 --> 00:07:42,880
We retained what we called 
virtual IBC. 

142
00:07:42,880 --> 00:07:45,520
This enabled us to 
permissionlessly expand the IBC 

143
00:07:45,520 --> 00:07:48,840
network, but we shifted the 
underlying architecture from 

144
00:07:48,840 --> 00:07:52,840
using common BFT as a layer one 
to using the OP stack for 

145
00:07:52,840 --> 00:07:56,080
settlement and chain derivation 
from Ethereum. 

146
00:07:56,840 --> 00:07:59,160
And this with this new solution,
that's basically what we've been

147
00:07:59,160 --> 00:08:03,560
working on for over a year now 
and what we'll be launching main

148
00:08:03,560 --> 00:08:06,400
net with very soon. 
Yeah, very cool. 

149
00:08:06,400 --> 00:08:08,200
Yeah. 
I think like this, this idea 

150
00:08:08,200 --> 00:08:12,120
that, you know, we would have 
thousands and then perhaps like 

151
00:08:12,120 --> 00:08:17,200
millions of of app chains 
hasn't, hasn't really changed. 

152
00:08:17,200 --> 00:08:22,240
It's just like what has changed 
is the level of sovereignty over

153
00:08:23,280 --> 00:08:27,760
settlement consensus. 
You know, I think logically app 

154
00:08:27,760 --> 00:08:33,240
chains have, you know, now moved
into this L2 territory, which 

155
00:08:33,240 --> 00:08:38,480
allows them to run with, you 
know, sufficient for most, I 

156
00:08:38,480 --> 00:08:42,600
think sufficious sufficient 
guarantees on censorship 

157
00:08:42,600 --> 00:08:48,040
resistance and throughput while 
maintaining your reasonable 

158
00:08:48,040 --> 00:08:51,080
cost. 
Because as we've seen throughout

159
00:08:51,160 --> 00:08:55,840
this, this this cycle, you're 
maintaining a chain in the 

160
00:08:55,920 --> 00:08:59,040
traditional kind of Cosmos app 
chain sense running your valder 

161
00:08:59,040 --> 00:09:00,760
set. 
It's just like a lot of 

162
00:09:00,760 --> 00:09:04,080
inefficiencies there, starting 
by the fact that like most 

163
00:09:04,080 --> 00:09:06,040
Cosmos app chains have the same 
validators that are at least 

164
00:09:06,040 --> 00:09:11,200
like there's a huge overlap. 
But but this, this new model 

165
00:09:11,200 --> 00:09:15,600
kind of makes makes sense. 
You know, like you, you guys, 

166
00:09:15,680 --> 00:09:19,440
you guys publish this article 
on, on the scaling limits of L 

167
00:09:19,440 --> 00:09:22,720
ones and L twos, which I thought
was really interesting. 

168
00:09:22,720 --> 00:09:26,400
And it seems like with L ones, 
there's kind of a hard scaling 

169
00:09:26,400 --> 00:09:32,640
limit that, that the space is, 
you know, established and, and 

170
00:09:32,640 --> 00:09:34,920
is aware of. 
But then with L twos, it's, it's

171
00:09:34,920 --> 00:09:38,360
a little bit more blurry, or at 
least the scaling limits are not

172
00:09:38,360 --> 00:09:41,560
fully tested. 
Can you talk a little bit about 

173
00:09:41,560 --> 00:09:43,840
what those scale limits are and 
what we know about them? 

174
00:09:44,760 --> 00:09:48,240
Yeah, before we talk about it, 
I, I, I wanted to mention one 

175
00:09:48,240 --> 00:09:50,800
thing because you're on the 
topic of this like Aptain 

176
00:09:50,800 --> 00:09:55,280
thesis, moving from a bunch of a
layer ones to to layer twos. 

177
00:09:56,000 --> 00:09:58,960
It's like Ethereum is speed 
running the Cosmos playbook, 

178
00:09:59,840 --> 00:10:02,960
both from the tech perspective 
and also from the problems 

179
00:10:02,960 --> 00:10:05,800
perspective. 
I think the arguments being had 

180
00:10:05,800 --> 00:10:09,200
in Ethereum or arguments that 
happen in the Cosmos or have 

181
00:10:09,200 --> 00:10:11,680
been happening in the cosmos for
many years now, which is kind of

182
00:10:11,680 --> 00:10:13,800
funny. 
So more, more on the scaling 

183
00:10:13,800 --> 00:10:17,400
limits. 
I would say that there's if so, 

184
00:10:17,400 --> 00:10:21,720
maybe the way to frame this is 
from, if you would have imagine 

185
00:10:21,720 --> 00:10:25,960
a chart going from low scale, so
like very low TPS, very high 

186
00:10:25,960 --> 00:10:30,400
latency to really high scale, 
which is really high TPS, really

187
00:10:30,400 --> 00:10:33,000
low latency. 
You can imagine that there is a 

188
00:10:33,000 --> 00:10:35,320
number of bottlenecks that 
you're going to hit as as you go

189
00:10:35,320 --> 00:10:39,360
from 1 technology to the next. 
And in the article, I create 

190
00:10:39,360 --> 00:10:44,320
this diagram where I try to help
user readers visualize that you 

191
00:10:44,760 --> 00:10:47,280
end up hitting the first 
bottleneck, which is consensus. 

192
00:10:47,800 --> 00:10:50,840
And every consensus algorithm 
requires a certain number of 

193
00:10:50,840 --> 00:10:54,320
rounds of communication. 
It requires data, transaction 

194
00:10:54,320 --> 00:10:57,000
data to be gossiped over, some 
peer-to-peer network. 

195
00:10:58,000 --> 00:11:00,720
These are just kind of 
algorithmic things and, and data

196
00:11:00,720 --> 00:11:02,520
throughput things that that need
to happen. 

197
00:11:03,040 --> 00:11:06,280
And above the consensus layer or
the consensus algorithm 

198
00:11:06,280 --> 00:11:10,560
bottleneck layer, you have this 
network bandwidth, a bottleneck,

199
00:11:10,560 --> 00:11:14,320
meaning that if you want to 
account for home stakers, home 

200
00:11:14,320 --> 00:11:16,640
Internet connections are only so
fast. 

201
00:11:17,240 --> 00:11:20,960
Like for example, you can only, 
well, it's very hard to get a GB

202
00:11:20,960 --> 00:11:22,960
Internet connection in most 
parts of the world. 

203
00:11:23,560 --> 00:11:27,000
I think many folks in the West 
are fortunate to be able to have

204
00:11:27,000 --> 00:11:30,800
fiber optic cable into their a 
neighborhood and can't get some 

205
00:11:30,800 --> 00:11:32,960
of these connection connection 
speeds. 

206
00:11:33,320 --> 00:11:35,840
But even then, like the real 
connectivity speeds are are far 

207
00:11:35,840 --> 00:11:39,280
less than one GB. 
And if you look at you know, 

208
00:11:39,280 --> 00:11:42,200
some changes like Solada where 
they're requiring 10 to 25 

209
00:11:42,200 --> 00:11:46,440
gigabytes per second network 
links it, it doesn't work with 

210
00:11:46,560 --> 00:11:49,280
home staking. 
You end up having to put your 

211
00:11:49,480 --> 00:11:51,640
software into data centers 
because data centers can offer 

212
00:11:51,640 --> 00:11:55,360
anywhere between a 10 gigabytes 
to 100 gigabytes or more. 

213
00:11:55,920 --> 00:11:58,760
And then not only do you put 
them in the same data center, 

214
00:11:58,760 --> 00:12:02,600
you're actually in some cases 
push to put it in the same cloud

215
00:12:02,600 --> 00:12:05,760
provider because a lot of cloud 
providers maintain high 

216
00:12:05,760 --> 00:12:07,320
throughput between their data 
centers. 

217
00:12:07,600 --> 00:12:10,440
But if you want to go across 
different cloud provider data 

218
00:12:10,440 --> 00:12:13,520
centers, you may not have the 
network bandwidth that that that

219
00:12:13,520 --> 00:12:15,920
you need. 
So there's this that were 

220
00:12:15,920 --> 00:12:18,320
bandwidth limit that kind of 
like presents itself as a 

221
00:12:18,320 --> 00:12:22,000
ceiling for how fast or how 
scalable a layer 1 can be. 

222
00:12:22,720 --> 00:12:25,360
And then if you step beyond 
that, you're in this layer 2 

223
00:12:25,360 --> 00:12:28,000
territory where the layer 2 
doesn't necessarily need a 

224
00:12:28,000 --> 00:12:32,120
consensus algorithm. 
It doesn't necessarily or isn't 

225
00:12:32,120 --> 00:12:34,920
necessarily network bandwidth 
bottlenecked because you could 

226
00:12:35,240 --> 00:12:37,600
run like a central, I guess, 
single proposer, single 

227
00:12:37,600 --> 00:12:42,040
sequencer and just run extremely
high throughput through it. 

228
00:12:42,040 --> 00:12:45,560
And there's a number of teams 
exploring this design space, 

229
00:12:45,800 --> 00:12:48,880
Mega Eats being one of them. 
And this now becomes very 

230
00:12:48,880 --> 00:12:51,440
interesting because this is kind
of like the Wild West of 

231
00:12:51,440 --> 00:12:54,040
blockchain scaling, where like 
for the past few years people 

232
00:12:54,040 --> 00:12:57,320
have been working on L1 scaling 
and have really kind of pushed 

233
00:12:57,320 --> 00:12:58,920
the limits of what, what we can 
do there. 

234
00:12:58,920 --> 00:13:01,440
Like Solana monad's doing that 
as well. 

235
00:13:02,040 --> 00:13:05,280
And, and now you're seeing the 
layer twos that, you know, push 

236
00:13:05,280 --> 00:13:07,920
even further. 
So the the ceilings there may be

237
00:13:07,920 --> 00:13:11,320
in a few years time 1,000,000 
TPS on a layer two could be the 

238
00:13:11,480 --> 00:13:14,800
could be the new normal. 
Yeah. 

239
00:13:14,800 --> 00:13:17,200
I mean, one, one question. 
I, I, I guess like from the 

240
00:13:17,200 --> 00:13:19,520
perspective of experimentation, 
this is great, right, Because 

241
00:13:19,520 --> 00:13:25,400
we're getting lots of different 
teams working on different ways 

242
00:13:25,400 --> 00:13:29,360
to scale like L ones. 
I think like that that space has

243
00:13:29,360 --> 00:13:32,720
been explored, as you said, and 
then now L2's, you know, it in 

244
00:13:32,720 --> 00:13:37,240
the end, like, you know, when I,
when I, when I hear of a, a team

245
00:13:37,240 --> 00:13:40,480
building like another framework 
to build roll ups, I think like,

246
00:13:40,480 --> 00:13:42,920
Oh yeah, I could like yet 
another roll up framework like 

247
00:13:43,360 --> 00:13:47,520
and, and it, it feels like right
now, at least in the cycle, 

248
00:13:47,520 --> 00:13:50,800
we're still in the 
infrastructure phase or like if 

249
00:13:50,800 --> 00:13:53,320
you want to call it that there 
there's not like that many 

250
00:13:53,320 --> 00:13:56,240
applications and end user 
applications being built. 

251
00:13:56,240 --> 00:14:00,480
It's a lot of infrastructure. 
What's the end game here for all

252
00:14:00,480 --> 00:14:04,320
of these rollout frameworks? 
Yeah, I think it's. 

253
00:14:04,320 --> 00:14:08,680
Everyone's going to have a 
different opinion and I think 

254
00:14:09,160 --> 00:14:13,200
people over index on zero 
knowledge here. 

255
00:14:14,400 --> 00:14:17,000
I say that because not because 
I'm a I'm not a fan of 0 

256
00:14:17,000 --> 00:14:19,640
knowledge. 
I in fact, I, I've thoroughly 

257
00:14:19,640 --> 00:14:23,880
enjoyed learning about zero 
knowledge tech and also working 

258
00:14:23,880 --> 00:14:28,800
on zero knowledge tech as well. 
But from the perspective of cost

259
00:14:28,800 --> 00:14:34,200
and scale, I think 0 knowledge 
tech is in a catch all. 

260
00:14:34,200 --> 00:14:38,000
I don't think that everything in
like the future state is all 

261
00:14:38,000 --> 00:14:42,840
going to be ZK verified. 
And I think that different teams

262
00:14:42,840 --> 00:14:45,680
will end up optimizing for 
different workloads. 

263
00:14:46,360 --> 00:14:49,320
And that's kind of why the app 
chain thesis exists. 

264
00:14:50,560 --> 00:14:55,400
To give you an analogy here, or 
maybe something from my a story 

265
00:14:55,400 --> 00:14:59,960
from my past when I was working 
at Uber, internally at Uber, you

266
00:14:59,960 --> 00:15:02,680
could use like generic database 
systems. 

267
00:15:02,680 --> 00:15:05,960
So maybe the analogy here is 
like, use a generic database, 

268
00:15:06,280 --> 00:15:08,480
use the EVM. 
So EVM is like generic compute. 

269
00:15:08,480 --> 00:15:10,200
You can pretty much write 
whatever program that you want 

270
00:15:10,200 --> 00:15:13,320
in it and you and then you 
write, run it in this runtime, 

271
00:15:13,320 --> 00:15:16,320
which is actually emulated in a,
in a, in an actual runtime on 

272
00:15:16,320 --> 00:15:21,880
your hardware. 
But from a efficiency 

273
00:15:21,880 --> 00:15:25,600
perspective, these generic 
databases are not cost effective

274
00:15:25,760 --> 00:15:28,640
or you need to add a ton of 
hardware to get the same amount 

275
00:15:28,640 --> 00:15:31,760
of work done. 
So when I was at Uber, what 

276
00:15:31,760 --> 00:15:34,840
ended up happening is that as 
Uber scaled as a business, they 

277
00:15:34,840 --> 00:15:37,640
started shifting away from, OK, 
we can't actually use these 

278
00:15:37,640 --> 00:15:40,000
generic databases. 
This is costing us way too much 

279
00:15:40,000 --> 00:15:41,440
money. 
We need to save on 

280
00:15:41,440 --> 00:15:44,280
infrastructure costs. 
And as we were trying to save on

281
00:15:44,280 --> 00:15:47,240
these infrastructure costs, they
started developing specialized 

282
00:15:47,240 --> 00:15:48,680
databases. 
They were like, OK, we have 

283
00:15:48,920 --> 00:15:52,080
these different workloads. 
Let's take each workload, make a

284
00:15:52,080 --> 00:15:55,640
database that's specifically 
optimized for that one workload.

285
00:15:55,960 --> 00:15:57,320
Because you get these huge 
benefits, right? 

286
00:15:57,320 --> 00:16:00,360
Like you get benefits around how
you encode the data. 

287
00:16:00,360 --> 00:16:02,760
Because you can say that I only 
have a certain type of data that

288
00:16:02,760 --> 00:16:04,000
goes into this. 
I'm going to create this 

289
00:16:04,200 --> 00:16:07,280
compression algorithm custom 
just for this one workload. 

290
00:16:07,840 --> 00:16:10,720
I'm going to create a search 
algorithm custom just for this 

291
00:16:10,720 --> 00:16:14,000
one workload indexing algorithm 
custom and and now you get into 

292
00:16:14,000 --> 00:16:17,520
a world where like you can save 
9095% on your infrastructure 

293
00:16:17,520 --> 00:16:21,160
costs by running these 
specialized databases for these 

294
00:16:21,160 --> 00:16:24,120
specialized workloads that you 
couldn't get otherwise with this

295
00:16:24,120 --> 00:16:27,320
generic like EDM or generic like
a regular database. 

296
00:16:27,960 --> 00:16:29,400
Right. 
So in this case you're like you,

297
00:16:29,440 --> 00:16:33,360
you're talking about it like 
using Postgres versus building 

298
00:16:33,360 --> 00:16:36,720
something custom in house or 
like using some framework that 

299
00:16:36,720 --> 00:16:38,560
allows you to do your own custom
database. 

300
00:16:39,120 --> 00:16:41,760
Yeah, yeah, exactly like Edward 
there was like I think, I 

301
00:16:41,760 --> 00:16:44,680
believe they were using 
Cassandra for their time series 

302
00:16:44,800 --> 00:16:47,400
data at one point, but they 
ended up using way too many 

303
00:16:47,400 --> 00:16:48,920
resources. 
So they switched over to 

304
00:16:48,920 --> 00:16:52,400
building their own called custom
time series database which I 

305
00:16:52,400 --> 00:16:56,760
ended up working on called M3DB.
No, that's interesting. 

306
00:16:56,760 --> 00:17:00,400
OK. 
I mean, I guess like, yeah, if 

307
00:17:00,400 --> 00:17:02,960
you haven't like worked in that 
environment, right? 

308
00:17:02,960 --> 00:17:07,480
Or like built a custom database,
like most, most, most developers

309
00:17:07,520 --> 00:17:11,880
will build their web app build, 
you know, using whatever, you 

310
00:17:11,880 --> 00:17:15,920
know, like Postgres and no jazz 
and like off the shelf 

311
00:17:15,920 --> 00:17:19,119
components. 
When you get to like a certain 

312
00:17:19,119 --> 00:17:24,880
scale, you, you have to build 
your own highly scalable, highly

313
00:17:24,880 --> 00:17:29,880
cost effective systems. 
Where or like where do you see 

314
00:17:29,880 --> 00:17:34,120
the overlap with between that 
and you know crypto as things 

315
00:17:34,120 --> 00:17:39,480
are currently going? 
I think the applications need to

316
00:17:40,080 --> 00:17:44,440
find the a balance here. 
So I'm still a proponent of if 

317
00:17:44,440 --> 00:17:47,600
you have an application, you 
have no users and you want to 

318
00:17:47,760 --> 00:17:51,760
like get an MVP out, write it in
Solidity, deployed on the EVM, 

319
00:17:51,760 --> 00:17:54,800
deployed in an existing 
blockchain, and look for PMF 

320
00:17:54,800 --> 00:17:56,560
first. 
I think like going out and 

321
00:17:56,680 --> 00:17:59,760
building an app chain ahead of 
finding PMF is probably not the 

322
00:17:59,760 --> 00:18:04,200
right approach unless there's 
like clear reasons for why it 

323
00:18:04,200 --> 00:18:06,800
doesn't work. 
So I, I like, I really like the 

324
00:18:06,800 --> 00:18:13,000
story protocol journey so far. 
Maybe not some of the social 

325
00:18:13,480 --> 00:18:18,080
commentary going on in, in, in, 
in Twitter and some of the, I 

326
00:18:18,080 --> 00:18:20,960
guess, like social tension 
there, But from a technical 

327
00:18:20,960 --> 00:18:22,160
perspective, it's very 
interesting. 

328
00:18:22,160 --> 00:18:25,880
So they had this journey from 
writing a bunch of smart 

329
00:18:25,880 --> 00:18:29,720
contracts and then they were 
working on building it over like

330
00:18:29,720 --> 00:18:33,040
a generic OB stack EVML 2. 
They tried implementing a graph 

331
00:18:33,040 --> 00:18:36,400
traversal algorithm in that EVM.
It turned out to be highly 

332
00:18:36,400 --> 00:18:38,440
inefficient. 
And they're like, we should, we 

333
00:18:38,440 --> 00:18:40,960
need a different environment 
execution environment for this 

334
00:18:40,960 --> 00:18:43,040
and we need to something that's 
a little more efficient for what

335
00:18:43,040 --> 00:18:45,080
we want to do. 
And they ultimately ended up 

336
00:18:45,080 --> 00:18:50,360
arriving on the Cosmos SDK and 
in our building what they call 

337
00:18:50,360 --> 00:18:53,960
like a purpose built chain for 
their specific use case. 

338
00:18:56,040 --> 00:18:57,920
OK. 
Yeah, No, that makes sense. 

339
00:18:58,880 --> 00:19:03,840
So let's maybe talk a little bit
about IBC here, because I think 

340
00:19:03,840 --> 00:19:10,480
a lot of people, you know, see 
Polymer as like building IBC for

341
00:19:10,480 --> 00:19:13,600
Etherium or like implementing 
IBC on Etherium. 

342
00:19:13,600 --> 00:19:16,400
If you just like sort of heard 
of Polymer, think like that's 

343
00:19:16,400 --> 00:19:19,600
probably a, a, a very generic 
way to think about what you guys

344
00:19:19,600 --> 00:19:21,360
are doing. 
Of course, you know, it's much 

345
00:19:21,360 --> 00:19:25,840
broader than that, but like I do
want to talk about IBCA little 

346
00:19:25,840 --> 00:19:29,520
bit and I think there are still 
some misconceptions about what 

347
00:19:29,520 --> 00:19:32,560
IBC is and confusing the 
transport layer and the 

348
00:19:32,560 --> 00:19:34,000
messaging layer. 
This is something we talked 

349
00:19:34,000 --> 00:19:35,920
about on the last podcast 
together early in Europe. 

350
00:19:37,000 --> 00:19:40,600
So maybe you just give a high 
level overview of like what is 

351
00:19:40,600 --> 00:19:45,000
IBC and you know, how is it? 
How is it fundamentally 

352
00:19:45,000 --> 00:19:48,960
different from some of the other
interoperability products that 

353
00:19:48,960 --> 00:19:53,560
exist that people are familiar 
with, you know like Hyperlane or

354
00:19:54,200 --> 00:19:57,880
AXLR, like you know, layer 0, 
etcetera? 

355
00:19:59,240 --> 00:20:04,200
So actually since we've had that
conversation, I'll say that 

356
00:20:04,200 --> 00:20:07,320
there are a number of protocols 
that are kind of moving in, in 

357
00:20:07,320 --> 00:20:10,800
the, in the same direction in 
terms of splitting out the 

358
00:20:10,800 --> 00:20:13,680
stack. 
So you, you notice how like 

359
00:20:13,680 --> 00:20:17,200
since then layer 0 has kind of 
like modularized their stack. 

360
00:20:17,200 --> 00:20:19,840
They're like, oh, we need to 
separate, separate verification.

361
00:20:20,280 --> 00:20:23,920
From execution which which, 
which is a valid design and that

362
00:20:23,920 --> 00:20:26,600
that's the design that IBC took.
So if you think of IBC or 

363
00:20:26,600 --> 00:20:31,240
interop is in three layers, you 
have application transport and 

364
00:20:32,560 --> 00:20:37,560
verification or or state that 
most protocols are trying to 

365
00:20:37,560 --> 00:20:40,160
move into this area where they 
are splitting those layers up 

366
00:20:40,160 --> 00:20:42,680
there are kind of allowing 
people to supply different 

367
00:20:42,680 --> 00:20:44,400
verification mechanisms and so 
on. 

368
00:20:45,520 --> 00:20:48,240
So now I would say the, the 
major differentiator is, is not 

369
00:20:48,280 --> 00:20:52,400
in that like 3 layer design, 
it's in that obviously just 

370
00:20:52,400 --> 00:20:56,280
offers a lot of features in that
transport layer. 

371
00:20:56,720 --> 00:20:59,080
And a lot of these features are 
forward-looking. 

372
00:20:59,080 --> 00:21:03,120
So from a from a practical 
perspective, a lot of 

373
00:21:03,120 --> 00:21:07,040
applications may not want or 
need these features at the 

374
00:21:07,040 --> 00:21:10,640
moment, but there will be a time
where applications are complex 

375
00:21:10,640 --> 00:21:12,680
enough that they'll be able to 
leverage a lot of these 

376
00:21:12,680 --> 00:21:15,320
features. 
And these features range from 

377
00:21:15,480 --> 00:21:19,120
everything messaging related, 
meaning that I can send a 

378
00:21:19,120 --> 00:21:23,040
packet, I can receive an 
acknowledgement or a time out to

379
00:21:23,040 --> 00:21:26,640
things like authentication, to 
things like versioning and 

380
00:21:26,640 --> 00:21:28,640
upgrades. 
Because even when you think 

381
00:21:28,640 --> 00:21:32,240
about one problem alone, like 
upgrades and and versioning of 

382
00:21:32,240 --> 00:21:35,200
an application across many 
chains, it's actually kind of a 

383
00:21:35,440 --> 00:21:38,800
tricky problem. 
It's not as simple as I'm just 

384
00:21:38,800 --> 00:21:41,840
going to like easily upgrade my 
application across all these 

385
00:21:41,840 --> 00:21:44,360
chains because each chain is, 
is, is a different place. 

386
00:21:44,360 --> 00:21:47,240
You can't atomically do that. 
So you have to handle all these 

387
00:21:47,240 --> 00:21:50,200
edge cases. 
And one edge case could be, just

388
00:21:50,200 --> 00:21:53,400
to give you an example, is the 
crossing Halos problem. 

389
00:21:53,960 --> 00:21:56,600
What if you have an upgrade 
initiated from three different 

390
00:21:56,600 --> 00:21:58,880
chains all at once? 
How, how do you resolve that? 

391
00:21:58,880 --> 00:22:00,880
What if, what if you have 
messages that aren't flush for 

392
00:22:00,880 --> 00:22:04,680
the old version that you know in
the middle of the upgrade? 

393
00:22:04,680 --> 00:22:06,280
How do you, how do you handle 
like flushing of these old 

394
00:22:06,280 --> 00:22:09,160
transactions? 
And, and like the IVC designers 

395
00:22:09,160 --> 00:22:11,640
have had a lot of conversations 
around this. 

396
00:22:11,640 --> 00:22:13,560
If you could go look at the 
specs, there's a lot of debate 

397
00:22:13,560 --> 00:22:17,040
on every single topic and it's 
good to be able to build off of 

398
00:22:17,040 --> 00:22:20,640
that, that debate. 
Another interesting thing for us

399
00:22:20,640 --> 00:22:26,160
is obviously also makes 
coordination happen on chain 

400
00:22:26,160 --> 00:22:28,120
versus off chain. 
There's something that we didn't

401
00:22:28,120 --> 00:22:31,240
get to talk about in the last 
podcast, but it's something that

402
00:22:31,280 --> 00:22:34,440
is becoming very clear that is a
differentiator of IVC from its 

403
00:22:34,440 --> 00:22:38,400
competitors is that a lot of 
competitors that you, they'll 

404
00:22:38,400 --> 00:22:43,160
use identifiers such as chain ID
for communicating between 

405
00:22:43,160 --> 00:22:45,120
chains. 
And if you think about what a 

406
00:22:45,120 --> 00:22:49,400
chain ID means, you realize that
that's not uniquely enforceable 

407
00:22:49,400 --> 00:22:53,880
or programmatically enforceable 
on chain, meaning that you have 

408
00:22:53,880 --> 00:22:56,280
to have social consensus around 
chain IDs because anyone, any 

409
00:22:56,280 --> 00:22:59,000
team can join a network and say,
like, you know what I, my chain 

410
00:22:59,000 --> 00:23:01,600
ID is also Etherium or like I'm 
also Etherium. 

411
00:23:02,680 --> 00:23:06,000
And from IBC perspective, you 
have this concept of connection 

412
00:23:06,000 --> 00:23:09,440
IDs and channel IDs, channel 
IDs, uniquely identified 

413
00:23:09,440 --> 00:23:13,440
application connection IDs 
uniquely identify a chain. 

414
00:23:14,000 --> 00:23:17,640
And think, if you think about a 
connection IDs and, and channel 

415
00:23:17,640 --> 00:23:19,520
IDs from the perspective of a 
map. 

416
00:23:19,960 --> 00:23:23,880
So you, let's say you have this 
like universe of chains and 

417
00:23:23,880 --> 00:23:27,320
every chain has a map and every 
chain has a unique map that they

418
00:23:27,320 --> 00:23:31,200
own of the rest of the network. 
That's what IBC gives each of 

419
00:23:31,200 --> 00:23:32,600
these chains. 
That means each chain has 

420
00:23:32,600 --> 00:23:35,960
sovereign ownership over what 
they see or their view of the 

421
00:23:35,960 --> 00:23:38,560
rest of the Galaxy. 
And, and this is also 

422
00:23:38,560 --> 00:23:41,840
programmatically enforceable so 
that all of all coordination 

423
00:23:41,840 --> 00:23:44,920
happens on chain versus like 
having had, having to have 

424
00:23:44,920 --> 00:23:47,800
social consensus, having to have
a centralized real layer set 

425
00:23:47,800 --> 00:23:51,640
that just knows what to do. 
This kind of prevents bad actors

426
00:23:51,640 --> 00:23:55,080
from, you know, misrepresenting 
themselves and, and, and and so 

427
00:23:55,080 --> 00:23:56,920
on. 
So it's it's a very unique 

428
00:23:56,920 --> 00:24:02,360
design and and unique to IVC. 
How much of Ibc's design do you 

429
00:24:02,360 --> 00:24:10,560
think is inspired by the designs
of like TCPIP and networking 

430
00:24:10,560 --> 00:24:15,520
protocols? 
I would say that it is very much

431
00:24:15,520 --> 00:24:19,480
inspired by TCPIPI think. 
I believe they use like Crisco's

432
00:24:19,480 --> 00:24:24,000
and a lot of the original IBC 
team used TCPIP as a model for 

433
00:24:24,000 --> 00:24:26,880
which to base their protocol off
of. 

434
00:24:27,400 --> 00:24:30,280
Like the handshaking protocol is
to prevent like man in the 

435
00:24:30,280 --> 00:24:33,840
middle attacks. 
There's authentication baked in 

436
00:24:34,240 --> 00:24:37,120
kind of similar to like ATCP 
connection, which is like an 

437
00:24:37,120 --> 00:24:38,840
authenticated like port 
essentially. 

438
00:24:39,280 --> 00:24:44,480
And even the port concept is I 
think port from this, this 

439
00:24:44,480 --> 00:24:47,920
concept of like TCP ports. 
So there's, there's a lot of 

440
00:24:48,040 --> 00:24:49,640
similarities there. 
The ports are a little bit 

441
00:24:49,640 --> 00:24:52,160
different. 
Like port in in IBC land is kind

442
00:24:52,160 --> 00:24:57,520
of like a a spark contract and 
and a port in TCP land is a is 

443
00:24:57,520 --> 00:25:00,760
an actual socket on your on your
computer in. 

444
00:25:02,120 --> 00:25:04,400
Yeah, yeah, That's interesting. 
Yeah. 

445
00:25:04,480 --> 00:25:11,000
You, you gave a talk at Modular 
Summit, you know, describing the

446
00:25:11,800 --> 00:25:17,080
evolution of network protocols. 
And I, I didn't realize that 

447
00:25:17,080 --> 00:25:21,760
there were so many, you know, 
that kind of came up in the 70s 

448
00:25:21,760 --> 00:25:25,920
and 80s and, and then died out 
even as late as the 2000s. 

449
00:25:26,400 --> 00:25:31,000
And one interesting thing about 
that talk was your description 

450
00:25:31,000 --> 00:25:35,680
of like how network topology 
manifests where you have like 

451
00:25:35,720 --> 00:25:39,640
Wan and then you have, you know,
lands and then you may have like

452
00:25:39,640 --> 00:25:43,760
virtual lands. 
How does that overlap with the 

453
00:25:43,840 --> 00:25:47,200
landscape of interoperability 
protocols today? 

454
00:25:47,280 --> 00:25:55,320
But but also, you know, as we 
have more and more L2's, but all

455
00:25:55,320 --> 00:25:58,600
sorts of L ones, you know, how 
does that overlap with the 

456
00:25:58,600 --> 00:26:02,680
landscape and the topology of 
applications and and L ones and 

457
00:26:03,680 --> 00:26:05,800
in crypto? 
Yeah. 

458
00:26:06,960 --> 00:26:12,360
To give viewers some background 
here, in the early 70s and 80s, 

459
00:26:12,360 --> 00:26:15,640
you had a lot of different 
intranets being built. 

460
00:26:16,200 --> 00:26:19,800
And the what was happening was a
lot of different companies had, 

461
00:26:19,920 --> 00:26:23,160
maybe they had a lot of devices 
like Xerox is, is an example, 

462
00:26:23,160 --> 00:26:27,160
one of them that wanted to have 
those and wanted to have those 

463
00:26:27,160 --> 00:26:29,320
devices networked or connected 
to each other. 

464
00:26:29,920 --> 00:26:34,000
So they developed their own 
protocols for how these clusters

465
00:26:34,000 --> 00:26:37,280
of devices would communicate. 
And, and let's just call these 

466
00:26:37,280 --> 00:26:39,960
like local area networks and 
these protocols, local area 

467
00:26:39,960 --> 00:26:44,720
network protocols. 
We're starting to see the same 

468
00:26:44,720 --> 00:26:47,080
thing happen in the roll up 
landscape. 

469
00:26:47,640 --> 00:26:50,640
Each roll up ecosystem is 
essentially building their own 

470
00:26:50,640 --> 00:26:56,080
like native interop solution and
these solutions can be like made

471
00:26:56,080 --> 00:27:01,400
analogous to local area network 
protocols from thirdly Internet.

472
00:27:02,240 --> 00:27:05,920
I in in the talk I call these 
virtual local area networks. 

473
00:27:06,720 --> 00:27:10,560
If you think of maybe the AG 
layer as one virtual local area 

474
00:27:10,560 --> 00:27:15,760
network, and I define this as 
the roll ups in that network or 

475
00:27:15,760 --> 00:27:19,640
either directly or have 1° of 
separation in between them. 

476
00:27:19,640 --> 00:27:22,160
So either they're connected to a
central hub or they're connected

477
00:27:22,160 --> 00:27:26,120
directly to one another. 
And optimism is doing this, 

478
00:27:27,280 --> 00:27:29,720
arbitrary is doing this. 
And now you start to see you 

479
00:27:29,720 --> 00:27:32,720
have all these different virtual
local area networks that are 

480
00:27:32,720 --> 00:27:35,760
spotting up each kind of with 
their own separate protocols. 

481
00:27:35,760 --> 00:27:38,840
And this is very similar to what
happened in in the 70s and 80s. 

482
00:27:39,640 --> 00:27:43,440
But you also started to see that
there was the growth of ARPANET.

483
00:27:43,440 --> 00:27:48,800
So ARPANET adopted TCPIP and I 
kind of equate ARP, the early 

484
00:27:48,800 --> 00:27:52,680
ARPANET to the early Interchain.
And I, I have these like 

485
00:27:53,360 --> 00:27:55,960
diagrams where I show early 
ARPANET where you had a few 

486
00:27:55,960 --> 00:28:00,120
colleges connected to one 
another and early a screenshot 

487
00:28:00,120 --> 00:28:03,560
of map of zones where you have 
just a few of these Cosmos L 

488
00:28:03,560 --> 00:28:06,600
ones connected to each other. 
And now as we're entering a 

489
00:28:06,600 --> 00:28:10,000
growth phase for the IBC network
with Interchain, you start to 

490
00:28:10,000 --> 00:28:14,080
see a lot more of these 
different ecosystem or different

491
00:28:14,080 --> 00:28:16,960
virtual local area network 
clusters being connect, 

492
00:28:16,960 --> 00:28:20,720
connected to this wider area 
network or, or Wan. 

493
00:28:21,240 --> 00:28:26,840
And over time, this Wan I, I use
the term virtual Wan in the in 

494
00:28:26,840 --> 00:28:31,520
the blockchain setting starts to
consume these virtual local area

495
00:28:31,520 --> 00:28:35,880
networks. 
And at some point, the custom 

496
00:28:36,120 --> 00:28:38,920
networking protocols that are 
used within the clusters are 

497
00:28:38,920 --> 00:28:43,960
deprecated in favor of TCPIP or 
I believe in, you know, perhaps 

498
00:28:43,960 --> 00:28:48,000
like 10 to 20 years will be 
deprecated fully in favor of 

499
00:28:48,000 --> 00:28:50,800
something like IBC or a variant 
of IBC. 

500
00:28:52,440 --> 00:28:55,480
Why do you equate IBC to TCPIP? 
Like what? 

501
00:28:55,880 --> 00:29:00,840
What gives you the certainty 
that IBC is the protocol that, 

502
00:29:01,000 --> 00:29:05,960
you know, in this kind of 
Internet story Mirrors, TCPIP 

503
00:29:06,320 --> 00:29:12,640
and all the other ones are, you 
know, equated to like Apple Talk

504
00:29:12,640 --> 00:29:15,640
and all these other, you know, 
networking protocols that no 

505
00:29:15,640 --> 00:29:19,200
longer exist? 
I think there's a angle of 

506
00:29:19,440 --> 00:29:25,920
credible neutrality where TCPIP 
like IBC was adopted across 

507
00:29:25,920 --> 00:29:30,000
different ecosystems and 
ultimately became not associated

508
00:29:30,000 --> 00:29:34,520
with anyone company. 
Whereas a lot of these roll up 

509
00:29:34,520 --> 00:29:37,880
ecosystem specific protocols are
used within a single ecosystem. 

510
00:29:37,880 --> 00:29:41,120
This is not to say that there 
may be contenders because TCPIP 

511
00:29:41,120 --> 00:29:45,360
also had competitors as well. 
So besides the credible 

512
00:29:45,360 --> 00:29:48,640
neutrality point, there's also a
technical angle. 

513
00:29:49,280 --> 00:29:52,560
So if you look at or if you 
evaluate every single interop 

514
00:29:52,560 --> 00:29:55,280
protocol today, whether that's a
native interop protocol, the 

515
00:29:55,280 --> 00:29:59,880
roll up ecosystem, or a third 
party interop protocol made by 

516
00:29:59,880 --> 00:30:03,800
some of these other interop 
providers, you'll see that IBC 

517
00:30:03,800 --> 00:30:07,680
is the only interop protocol 
that's even capable of operating

518
00:30:07,680 --> 00:30:11,480
in a wide area network fashion. 
Meaning that it's the only 

519
00:30:11,480 --> 00:30:15,280
protocol that allows two parties
or two chains to communicate 

520
00:30:15,280 --> 00:30:19,880
directly while being physically 
indirectly connected. 

521
00:30:20,000 --> 00:30:22,760
Meaning that there could be more
than 1° of separation. 

522
00:30:22,960 --> 00:30:25,600
So maybe there's like 2 chains 
in this network that are 

523
00:30:25,640 --> 00:30:28,960
separated by 10 hops. 
They can still efficiently 

524
00:30:28,960 --> 00:30:32,600
communicate directly to one 
another via multi hop IBC 

525
00:30:32,600 --> 00:30:36,200
channels, which is different 
from multi hop IBC packet 

526
00:30:36,200 --> 00:30:38,000
forwarding. 
Those are kind of like two 

527
00:30:38,000 --> 00:30:41,520
different solutions. 
But yeah, IB, CS, the 1st to 

528
00:30:41,520 --> 00:30:44,400
have this property and, and, and
this technology and, and 

529
00:30:44,400 --> 00:30:46,240
behaving this way. 
So it's kind of, it's in the 

530
00:30:46,240 --> 00:30:49,240
lead now. 
I guess time will tell what what

531
00:30:49,240 --> 00:30:51,080
happens. 
What happens here? 

532
00:30:52,120 --> 00:30:53,480
Right. 
So that's kind of mirrors 

533
00:30:53,480 --> 00:31:00,160
routing in TCPIP where, you 
know, I, my computer is nowhere 

534
00:31:00,160 --> 00:31:03,360
near your computer and there may
be like four or five degrees of 

535
00:31:03,360 --> 00:31:06,720
separation, but we're still able
to communicate because, you 

536
00:31:06,720 --> 00:31:10,840
know, there's a network of, of 
data centers that like will 

537
00:31:10,840 --> 00:31:14,920
relay those packets through, you
know, the Internet and like 

538
00:31:15,080 --> 00:31:17,640
oversee cables, etcetera. 
Interesting. 

539
00:31:17,880 --> 00:31:19,720
Yeah. 
And and it's only protocol that 

540
00:31:19,720 --> 00:31:23,240
allows you to. 
I always say that the the 

541
00:31:23,240 --> 00:31:26,840
difference is because you can 
try to do multi hop packet 

542
00:31:26,840 --> 00:31:28,680
forwarding with some of these 
other existing interop 

543
00:31:28,680 --> 00:31:30,760
protocols. 
But the major difference is that

544
00:31:30,760 --> 00:31:34,640
with multi hop IBC channels, 
what you're actually propagating

545
00:31:34,640 --> 00:31:37,840
through the network is 
compressed state mean that it's 

546
00:31:37,840 --> 00:31:41,640
the like compressed state of all
of the chains is being gossiped 

547
00:31:41,640 --> 00:31:45,440
across the the network and the 
packets themselves. 

548
00:31:45,440 --> 00:31:48,480
The actual data which is 
uncompressed is only made it at 

549
00:31:48,480 --> 00:31:51,440
the source and the destination, 
so this uncompressed data does 

550
00:31:51,440 --> 00:31:54,720
not flow in between, which makes
for a far more efficient 

551
00:31:54,720 --> 00:31:57,280
communication than with with 
alternative methods. 

552
00:31:58,280 --> 00:32:00,320
OK, I didn't know that. 
Cool. 

553
00:32:00,840 --> 00:32:02,960
Well, let's talk about the 
Polymer hub. 

554
00:32:03,000 --> 00:32:07,920
So one of the questions people 
on Twitter said I should ask you

555
00:32:07,920 --> 00:32:13,080
is when mainnet. 
And so I guess, I guess you 

556
00:32:13,080 --> 00:32:17,360
don't have an answer for that 
yet, but but but what we can 

557
00:32:17,360 --> 00:32:19,920
talk about what is going to be 
main net, which is the polymer 

558
00:32:19,920 --> 00:32:23,600
hub. 
So what what is the polymer hub?

559
00:32:23,600 --> 00:32:30,640
And like what role does it serve
as this interoperability hub for

560
00:32:30,640 --> 00:32:32,920
Ethereum? 
Because I think like one very 

561
00:32:32,920 --> 00:32:36,600
important thing for people to 
realize here is that there isn't

562
00:32:36,600 --> 00:32:40,480
a single interoperability 
standard for Ethereum roll ups. 

563
00:32:40,960 --> 00:32:45,200
And different roll ups have had 
to implement, you know, their 

564
00:32:45,200 --> 00:32:47,640
own probability solutions. 
Applications have had to 

565
00:32:47,640 --> 00:32:51,400
implement their own input and 
probability solutions, which is 

566
00:32:51,400 --> 00:32:53,360
kind of crazy when you're coming
from Cosmos, right? 

567
00:32:53,360 --> 00:32:57,920
But so yeah, let's let's talk 
about the hub and the what role 

568
00:32:58,040 --> 00:33:01,720
you know it in Sysserve. 
Yeah, I'll say that at a high 

569
00:33:01,720 --> 00:33:05,160
level it does implement IBC. 
We will bring that feature set 

570
00:33:05,160 --> 00:33:10,080
that we just discussed to these 
roll ups and using the like wide

571
00:33:10,080 --> 00:33:15,120
area network, local area network
analogy here Polymer hub 

572
00:33:15,120 --> 00:33:17,160
straddles these roll up 
ecosystems. 

573
00:33:18,240 --> 00:33:22,440
IBC as a standard similar to 
TCPIP straddles all these roll 

574
00:33:22,440 --> 00:33:26,320
up clusters and provides 
connectivity across cluster and 

575
00:33:26,320 --> 00:33:28,560
with the rest of the interchain 
as well. 

576
00:33:29,160 --> 00:33:33,240
So from like AAPI service 
perspective, you get the 

577
00:33:33,240 --> 00:33:36,520
standardized API for accessing 
all these different chains. 

578
00:33:38,160 --> 00:33:41,360
Additionally, I'll say that the 
So back to the kind of earlier 

579
00:33:41,360 --> 00:33:44,080
in this conversation we talked 
about the difference between 

580
00:33:44,080 --> 00:33:46,080
layer 2 and layer one scaling 
limits. 

581
00:33:47,080 --> 00:33:50,200
We're starting to see these roll
ups such as mega ETH push 

582
00:33:50,200 --> 00:33:54,400
towards 1 millisecond block 
times 100,000 TPS and perhaps 

583
00:33:54,400 --> 00:33:59,280
even a million TPS. 
And we realized that we needed 

584
00:33:59,280 --> 00:34:03,160
to build polymerize the L2 to be
even able to scale to the point 

585
00:34:03,160 --> 00:34:06,240
that we can support these, these
roll ups. 

586
00:34:06,240 --> 00:34:10,360
Because if you imagine you have 
a sovereign layer 1A hub and 

587
00:34:10,360 --> 00:34:14,199
spoke in our protocol and you're
trying to connect 2 megahertz to

588
00:34:14,199 --> 00:34:17,199
one another. 
But just consensus alone puts 

589
00:34:17,199 --> 00:34:20,400
puts your block time at, you 
know, like 100, like a few 100 

590
00:34:20,440 --> 00:34:24,440
milliseconds at, at the at the 
very, very least, usually like a

591
00:34:24,440 --> 00:34:28,520
few seconds. 
Then it's very hard to match 

592
00:34:28,920 --> 00:34:31,679
that, that latency. 
It's also very hard to match 

593
00:34:31,679 --> 00:34:35,960
that that throughput without 
making the solution very, very 

594
00:34:35,960 --> 00:34:38,600
centralized. 
Of course, if you put 3 nodes in

595
00:34:38,600 --> 00:34:41,320
one data center in the same 
server rack and you throw on 

596
00:34:41,320 --> 00:34:44,159
some consensus, you can probably
go very, very fast. 

597
00:34:44,560 --> 00:34:47,199
But then you're like closer to, 
but then you're like very 

598
00:34:47,199 --> 00:34:50,040
centralized and you don't really
have the decentralized 

599
00:34:50,280 --> 00:34:53,320
properties of a layer 2 because 
which which inherits those from 

600
00:34:53,320 --> 00:34:55,320
the layer 1. 
So there's like this scale 

601
00:34:55,320 --> 00:34:57,280
reason why we built Polymer Hub 
this way. 

602
00:34:58,240 --> 00:35:03,400
And the other reason is from a 
cost efficiency, a standpoint 

603
00:35:03,440 --> 00:35:08,520
and latency standpoint. 
So it's it's cost efficient in 

604
00:35:08,520 --> 00:35:12,360
that we can add different safety
features in a much more cost 

605
00:35:12,360 --> 00:35:15,800
efficient way than if you were 
to add those safety features in 

606
00:35:15,800 --> 00:35:19,120
a point to point protocol. 
So with a lot of point to point 

607
00:35:19,120 --> 00:35:21,320
protocols, perhaps you can 
handle the scale because you're 

608
00:35:21,320 --> 00:35:25,080
connecting these chains 
directly, but it's very cost 

609
00:35:25,080 --> 00:35:30,280
inefficient from checking things
like data availability, ordering

610
00:35:30,680 --> 00:35:33,720
and even validity. 
Because you imagine you partner 

611
00:35:33,720 --> 00:35:36,560
with a, a company like we're 
partnered with a company called 

612
00:35:36,560 --> 00:35:38,240
LaGrange. 
They're working on a solution 

613
00:35:38,240 --> 00:35:41,640
called LaGrange state 
committees, which offer, I guess

614
00:35:41,640 --> 00:35:44,360
a quote, UN quote like client 
for optimistic roll ups and 

615
00:35:44,360 --> 00:35:45,800
perhaps even other roll ups as 
well. 

616
00:35:47,080 --> 00:35:50,400
The issue there is if you want 
to connect using the state 

617
00:35:50,400 --> 00:35:53,440
committee solution in a point to
point fashion, you would have to

618
00:35:53,440 --> 00:35:58,160
generate a state committee proof
per chain in the network. 

619
00:35:59,000 --> 00:36:03,800
So this is going to be in chains
for like in connected chains at 

620
00:36:03,800 --> 00:36:07,400
some, some amount of latency. 
And then these proofs are not 

621
00:36:07,400 --> 00:36:10,880
going to be free or, or cheap 
to, to, to generate With 

622
00:36:10,880 --> 00:36:13,760
Polymer, we can stream all the 
attestations to our central hub 

623
00:36:13,760 --> 00:36:17,280
and only generate 1 proof for in
chains. 

624
00:36:17,880 --> 00:36:21,560
This becomes much more cost 
effective for us from a validity

625
00:36:21,560 --> 00:36:25,240
standpoint and we're able to to 
kind of like validate this 

626
00:36:25,240 --> 00:36:26,920
information across all these 
different chains. 

627
00:36:28,320 --> 00:36:31,600
So is this like ZK proof 
aggregation that you're using? 

628
00:36:33,160 --> 00:36:37,120
So I wanted, I think when people
would talk about ZK proof 

629
00:36:37,120 --> 00:36:39,800
aggregation in the context of 
the AG layer, they're talking 

630
00:36:39,800 --> 00:36:43,600
about ZK proofs of validity, 
meaning that this is a ZK proof 

631
00:36:43,600 --> 00:36:46,880
of the execution of a chain, of 
the full execution of a chain. 

632
00:36:47,440 --> 00:36:51,080
What I'm talking about here is a
ZK attestation. 

633
00:36:51,600 --> 00:36:55,120
So LaGrange State committee 
nodes are not generating AZK 

634
00:36:55,120 --> 00:36:58,640
proof for the execution of the 
chain, rather they're generating

635
00:36:58,640 --> 00:37:02,080
AZK proof of the attestation. 
So it's much more similar to a 

636
00:37:02,080 --> 00:37:07,080
light client, like a tenement 
light client than it is, I guess

637
00:37:07,080 --> 00:37:11,880
like AZKEVM, like like validity 
proof, ZK validity proof. 

638
00:37:13,000 --> 00:37:15,640
OK, got it. 
Can you talk a little bit about 

639
00:37:15,720 --> 00:37:20,240
Polymer Hobbs architecture and 
what it's built on? 

640
00:37:21,080 --> 00:37:24,480
Yes. 
So we're Cosmos SDK at the 

641
00:37:24,600 --> 00:37:27,800
application layer and we use 
this framework called Monomer 

642
00:37:28,560 --> 00:37:32,440
for us to be able to deploy this
Cosmos SDK app as a roll up over

643
00:37:32,440 --> 00:37:38,120
the OP stack. 
And the Monomer framework kind 

644
00:37:38,120 --> 00:37:42,080
of establishes a compatibility 
layer between the engine API, 

645
00:37:42,080 --> 00:37:45,880
which is expected by the OP 
stack, and ABCI, which is 

646
00:37:45,880 --> 00:37:49,000
expected by the Cosmos SDK 
application. 

647
00:37:49,720 --> 00:37:52,160
And the reason we wanted to 
build it this way, and so 

648
00:37:52,160 --> 00:37:54,360
there's some technical nuance 
here, so I'll dig in a little 

649
00:37:54,360 --> 00:38:00,000
bit, is that there is logic in 
the OP stack that derives the L2

650
00:38:00,000 --> 00:38:03,800
chain from the layer one. 
And this is useful for us from 

651
00:38:03,800 --> 00:38:07,640
an interoperability perspective,
meaning that if we can associate

652
00:38:07,640 --> 00:38:11,480
every layer 2 block with a 
specific layer one block, what 

653
00:38:11,480 --> 00:38:15,640
we can do is we can essentially 
communicate across different 

654
00:38:15,640 --> 00:38:18,840
layer twos beneath Etherium 
finality. 

655
00:38:20,280 --> 00:38:24,800
So today, most protocols either 
wait for a theorem finality or 

656
00:38:24,800 --> 00:38:28,000
they'll go faster than a theorem
finality and push this reorg 

657
00:38:28,000 --> 00:38:30,240
risk onto the applications 
themselves. 

658
00:38:31,160 --> 00:38:33,920
Then there's a trade off here to
be made and we're thinking of, 

659
00:38:34,120 --> 00:38:36,680
so how can we break this 
finality barrier? 

660
00:38:37,360 --> 00:38:40,920
And what we were able to do is 
we developed a reorg protect 

661
00:38:41,040 --> 00:38:44,040
protection protocol for sub 
finality communication across L 

662
00:38:44,040 --> 00:38:48,880
twos, which essentially builds a
dependency graph of transactions

663
00:38:49,200 --> 00:38:51,240
based on some history of the 
layer one. 

664
00:38:52,200 --> 00:38:55,360
And at the end of this finality 
period. 

665
00:38:55,360 --> 00:38:57,800
So once the theorem begins to 
finalize, we can have a 

666
00:38:57,800 --> 00:39:01,040
condition that says if these 
transactions that were built on 

667
00:39:01,040 --> 00:39:03,280
the history of Etherium, let's 
call that L1 prime. 

668
00:39:03,280 --> 00:39:06,440
If L1 prime gets finalized, we 
will commit this entire 

669
00:39:06,440 --> 00:39:07,920
dependency graph of 
transactions. 

670
00:39:08,520 --> 00:39:11,240
If L1 Prime does not get 
finalized, we will we will 

671
00:39:11,240 --> 00:39:16,680
revert this entire dependency 
graph so it offers additional 

672
00:39:16,680 --> 00:39:18,720
safety guarantees around 
communication at lower 

673
00:39:18,720 --> 00:39:21,080
latencies. 
Therefore, bringing reorg risk, 

674
00:39:21,200 --> 00:39:25,240
risk from the application level 
down into the protocol level and

675
00:39:25,240 --> 00:39:28,440
handling it in protocol while 
providing extremely low 

676
00:39:28,440 --> 00:39:31,600
latencies where we're trying to 
target less than 10 seconds. 

677
00:39:33,560 --> 00:39:37,560
OK, Maybe this is a good time to
talk about the different types 

678
00:39:37,560 --> 00:39:42,080
of finality and fast finality 
mechanisms that exist. 

679
00:39:42,680 --> 00:39:47,360
I was recently researching this 
for in the context of movement 

680
00:39:47,360 --> 00:39:53,200
labs and I saw that like talent 
was getting into some some some 

681
00:39:53,200 --> 00:39:57,120
debates with with Rushi about 
like what is a roll up and find 

682
00:39:57,120 --> 00:40:02,400
out etcetera. 
So, you know, maybe just going 

683
00:40:02,400 --> 00:40:05,920
across like the different types 
of finale finality mechanisms 

684
00:40:05,920 --> 00:40:07,760
and like. 
You know, if our listener is 

685
00:40:07,760 --> 00:40:10,200
explaining OK, like what are 
these pre confirmations and what

686
00:40:10,200 --> 00:40:13,000
are the different trade-offs and
like if we add faster finality 

687
00:40:13,000 --> 00:40:14,720
to that, like what are the 
trade-offs there as well? 

688
00:40:15,840 --> 00:40:18,920
Yeah. 
So I think there's some some 

689
00:40:18,920 --> 00:40:21,680
confusion around like what 
finality means. 

690
00:40:22,600 --> 00:40:27,240
So I'll, I'll start off by 
saying no protocol can guarantee

691
00:40:27,240 --> 00:40:31,040
fidelity on behalf of Ethereum. 
Ethereum has its own finality 

692
00:40:31,040 --> 00:40:33,520
mechanism. 
If you, if you attempt to 

693
00:40:33,520 --> 00:40:38,400
guarantee fidelity when you 
actually get is a completely 

694
00:40:38,400 --> 00:40:42,280
different role of construction. 
So if you know, hypothetically, 

695
00:40:42,280 --> 00:40:45,920
you were to say, there's this 
other consensus layer that I'm 

696
00:40:45,920 --> 00:40:49,480
going to define the, the 
canonical ordering of my chain 

697
00:40:49,480 --> 00:40:53,360
or my finality on. 
Now that chain becomes a roll up

698
00:40:53,360 --> 00:40:58,040
of that other consensus layer. 
So, and if you move down the 

699
00:40:58,040 --> 00:41:00,160
direction of this analogy, 
you'll, you'll start to find 

700
00:41:00,160 --> 00:41:02,920
that like, actually, this looks 
very much like the first version

701
00:41:02,920 --> 00:41:05,000
of Polygon. 
You have this like separate 

702
00:41:05,000 --> 00:41:08,680
consensus layer. 
You then define your finality 

703
00:41:08,680 --> 00:41:11,720
based on that consensus layer. 
And then you post a state 

704
00:41:11,720 --> 00:41:14,960
commitment to to to the Etherium
layer 1. 

705
00:41:15,880 --> 00:41:18,800
And that's basically a, a side 
chain more, more or less. 

706
00:41:20,360 --> 00:41:23,600
So for roll ups that do define 
their finality or like final 

707
00:41:23,600 --> 00:41:26,400
finality on Etherium, you can 
have something called a pre 

708
00:41:26,400 --> 00:41:28,960
confirmation. 
And what this is, it's a 

709
00:41:28,960 --> 00:41:33,320
guarantee or it's, it's a 
guarantee that if a a block 

710
00:41:33,320 --> 00:41:37,240
proposer gets a specific 
proposal slot that they will 

711
00:41:37,240 --> 00:41:39,440
include your transaction in that
slot. 

712
00:41:40,720 --> 00:41:44,600
But this is an optimistic 
guarantee, meaning that they 

713
00:41:44,600 --> 00:41:47,240
can't fully make this guarantee.
Basically what they're saying is

714
00:41:47,240 --> 00:41:52,520
that if my slot does not change 
and I proposed within that slot,

715
00:41:52,880 --> 00:41:55,520
then you will have your 
transaction included in the 

716
00:41:55,520 --> 00:41:58,600
chain. 
However, if there is a reorg and

717
00:41:58,600 --> 00:42:01,920
that proposer slot now becomes 
maybe perhaps moved further 

718
00:42:01,920 --> 00:42:05,080
away, now you find that that 
guarantee doesn't doesn't hold 

719
00:42:05,080 --> 00:42:08,600
anymore because the proposer no 
longer the the proposer has 

720
00:42:08,600 --> 00:42:11,920
essentially like lost their slot
for for the full guarantee, you 

721
00:42:11,920 --> 00:42:14,480
have to wait for full theorem 
finality, which is roughly 12 to

722
00:42:14,480 --> 00:42:17,960
16. 
Minutes OK and so this this 

723
00:42:17,960 --> 00:42:23,920
mechanism that this this reorg 
protection mechanism that you're

724
00:42:23,920 --> 00:42:27,920
implementing I think the term 
you use was it it's sub plants 

725
00:42:27,960 --> 00:42:31,440
etherium finality was that oh. 
No, no, it it, it, it does not. 

726
00:42:31,440 --> 00:42:33,040
It cannot replace Etherium 
finality. 

727
00:42:33,720 --> 00:42:37,800
Instead it's a, it's, it's sort 
of like a guarantee around 

728
00:42:37,800 --> 00:42:40,800
eventual finality. 
So it's an optimistic guarantee 

729
00:42:40,800 --> 00:42:44,000
the same way that pre, the same 
way that builder proposer pre 

730
00:42:44,000 --> 00:42:46,920
confirmations are also an 
optimistic guarantee. 

731
00:42:48,440 --> 00:42:51,720
So it's an optimistic guarantee 
on the Ethereum, on Ethereum's 

732
00:42:51,720 --> 00:42:55,240
finality. 
Yes, yes and but it but it has 

733
00:42:55,240 --> 00:43:01,040
guardrails in place where if the
the guarantee is not met then 

734
00:43:01,080 --> 00:43:05,120
the all the transactions that 
were committed or like I guess 

735
00:43:05,120 --> 00:43:08,080
pending by the protocol are all 
invalidated, which is a very 

736
00:43:08,080 --> 00:43:10,960
important guarantee. 
OK. 

737
00:43:11,160 --> 00:43:13,200
And then what happens to those 
transactions if they're 

738
00:43:13,200 --> 00:43:15,880
invalidated? 
So like as the user of the roll 

739
00:43:15,880 --> 00:43:19,080
up like how does that translate 
into your user experience of 

740
00:43:19,080 --> 00:43:22,920
like having just made a 
transaction that gets that gets 

741
00:43:22,920 --> 00:43:24,320
rolled back? 
Yeah. 

742
00:43:24,320 --> 00:43:28,600
So from user experience 
perspective, 99 point like 9% of

743
00:43:28,600 --> 00:43:31,240
the time their transactions 
going to go through. 

744
00:43:31,600 --> 00:43:35,320
This is not so dissimilar to 
using a layer 2 today. 

745
00:43:35,320 --> 00:43:38,640
So if you use unit swap on 
optimism today, you'll make a 

746
00:43:38,640 --> 00:43:42,040
swap, it'll say it's confirmed 
you get your assets and it'll 

747
00:43:42,040 --> 00:43:43,600
look like it all happened in 
like 2 seconds. 

748
00:43:43,600 --> 00:43:46,600
And that's what it'll look like 
to the user most of the time. 

749
00:43:46,960 --> 00:43:50,520
But then in like a tiny fraction
of the time, your, your swap 

750
00:43:50,520 --> 00:43:53,000
will just like disappear. 
You'd go, oh, actually I never 

751
00:43:53,000 --> 00:43:55,720
made this swap. 
I have my original asset and 

752
00:43:55,720 --> 00:43:58,520
that's a nice guarantee because 
that you if you have all these 

753
00:43:58,520 --> 00:44:00,200
different transactions 
interacting with each other 

754
00:44:00,200 --> 00:44:03,000
across chain, you never want to 
get into a state where there's a

755
00:44:03,000 --> 00:44:05,120
double spent. 
You never wanted to get into a 

756
00:44:05,120 --> 00:44:10,000
state where like what actor has 
made money on one chain and also

757
00:44:10,000 --> 00:44:12,800
like not never transferred their
funds on the original chain. 

758
00:44:13,280 --> 00:44:16,800
So in order to be able to make 
this guarantee across any number

759
00:44:16,800 --> 00:44:20,800
of roll ups, we had to have this
like atomic like protocol, like 

760
00:44:20,800 --> 00:44:23,600
atomic or conditional like 
commit over protocol. 

761
00:44:24,240 --> 00:44:26,880
So it's better to be. 
It's better to revert all the 

762
00:44:26,880 --> 00:44:29,800
transactions than to end up in 
an inconsistent state across the

763
00:44:29,800 --> 00:44:34,440
different chains. 
And so how does how does this 

764
00:44:34,440 --> 00:44:39,120
mechanism facilitate 
interoperability between 

765
00:44:39,120 --> 00:44:43,840
different etherium roll ups? 
What this allows is that for 

766
00:44:43,840 --> 00:44:47,840
Etherium roll ups that implement
the EIP 4788 standard, where 

767
00:44:47,840 --> 00:44:51,360
there is some layer one 
information on that roll up that

768
00:44:51,360 --> 00:44:54,880
we can utilize, we can allow 
those roll ups to communicate 

769
00:44:54,880 --> 00:44:57,360
essentially as close to block 
time as possible. 

770
00:44:58,320 --> 00:45:00,920
Meaning that the they'll be able
to, if they're producing blocks 

771
00:45:00,920 --> 00:45:02,880
at 2 seconds, they'll be able to
communicate at 2 seconds. 

772
00:45:02,880 --> 00:45:05,520
If they're producing blocks at 
100 milliseconds, they could 

773
00:45:05,520 --> 00:45:08,480
technically communicate 100 
milliseconds with. 

774
00:45:08,680 --> 00:45:11,560
I guess additional accounted for
additional like actual network 

775
00:45:11,560 --> 00:45:15,280
latency of this communication. 
Since we're still on the topic 

776
00:45:15,280 --> 00:45:19,680
of the Polymer hub here, you 
know for for roll ups that want 

777
00:45:19,840 --> 00:45:23,000
to utilize Polymer hub for 
interoperability. 

778
00:45:23,000 --> 00:45:29,200
So like Arbitrum you want to 
send assets on to base what what

779
00:45:29,200 --> 00:45:35,680
is required for those roll ups 
in order to on board or 

780
00:45:35,680 --> 00:45:38,240
integrate Polymer? 
Yeah. 

781
00:45:38,240 --> 00:45:41,400
So with our virtual IBCU 
protocol, it's completely 

782
00:45:41,400 --> 00:45:45,480
permissionless to integrate. 
So either the Polymer team or a 

783
00:45:45,480 --> 00:45:47,640
third party would be able to 
deploy our smart contracts 

784
00:45:47,640 --> 00:45:51,200
through the setup work. 
There's some IBC like specific 

785
00:45:51,200 --> 00:45:55,320
setup that's required, but 
there's no opt in by the layer 2

786
00:45:55,320 --> 00:45:58,440
like the layer 2 doesn't have to
opt in to using some like you 

787
00:45:58,440 --> 00:46:00,440
know, special process they have 
to run. 

788
00:46:00,440 --> 00:46:03,680
They don't have to change their 
deployment infrastructure like 

789
00:46:03,680 --> 00:46:04,920
nothing needs to change on their
end. 

790
00:46:06,560 --> 00:46:10,840
OK, so so it's it's 
permissionless for the roll up 

791
00:46:11,360 --> 00:46:15,560
a. 
A user can't permissionlessly 

792
00:46:15,560 --> 00:46:18,280
use Polymer interoperability 
without the role of having 

793
00:46:18,280 --> 00:46:23,000
implemented. 
It without having polymers 

794
00:46:23,000 --> 00:46:27,960
integration deployed, but 
technically we plan on making 

795
00:46:27,960 --> 00:46:30,600
this very easy to request 
connectivity to a new chain. 

796
00:46:31,480 --> 00:46:35,160
So for users that maybe aren't 
sophisticated enough to like run

797
00:46:35,160 --> 00:46:37,720
these scripts to do these 
deployments, we're planning on 

798
00:46:37,720 --> 00:46:41,120
automating all of this so that 
perhaps you could have like a 

799
00:46:41,320 --> 00:46:45,720
permissionless pipeline or some 
like loosely permission pipeline

800
00:46:45,720 --> 00:46:47,960
of just requests to like new 
deployments. 

801
00:46:48,400 --> 00:46:52,440
And this is true in the IBC 
network today, which if anyone 

802
00:46:52,440 --> 00:46:55,880
spends up a chain it, it does 
require some technical expertise

803
00:46:55,880 --> 00:46:57,880
to be able to set up a 
connection, set up a channel and

804
00:46:57,880 --> 00:47:01,680
so on, or set up an IBC relayer.
But we plan on providing some 

805
00:47:01,680 --> 00:47:04,400
like more user friendly front 
end for for that sort of thing. 

806
00:47:05,160 --> 00:47:07,880
So we've talked about Ethereum 
like essentially Polymer will 

807
00:47:07,880 --> 00:47:12,960
allow any, any roll up on it, 
any Ethereum based roll up to 

808
00:47:12,960 --> 00:47:17,200
interoperate over IBC. 
What about the existing IBC 

809
00:47:17,200 --> 00:47:21,040
ecosystem and sort of cosmos 
broadly, what does that look 

810
00:47:21,040 --> 00:47:23,360
like? 
And you know, is it, is it, is 

811
00:47:23,360 --> 00:47:27,040
it the case that kind of Polymer
sits at the middle and 

812
00:47:27,040 --> 00:47:32,920
interoperates with IBC as that 
kind of middle hop are are 

813
00:47:33,040 --> 00:47:37,880
Ethereum based roll ups going to
be able to send assets directly 

814
00:47:38,120 --> 00:47:42,960
to and from IBC the the IBC 
network? 

815
00:47:42,960 --> 00:47:47,240
So can I move assets from like 
osmosis to like some decks on 

816
00:47:47,240 --> 00:47:52,440
base permissionlessly? 
Yes, so they'll be able to use 

817
00:47:52,440 --> 00:47:55,400
the protocol permissionlessly. 
Although because of how our 

818
00:47:55,400 --> 00:48:00,000
virtual IBC protocol works, 
Polymer handles IBC execution 

819
00:48:00,000 --> 00:48:01,800
and implementation on behalf of 
the roll up. 

820
00:48:02,280 --> 00:48:05,920
So for a roll up that doesn't 
isn't communicating through 

821
00:48:05,920 --> 00:48:09,480
Polymer, they don't actually 
speak IBC so they wouldn't be 

822
00:48:09,480 --> 00:48:11,440
able to connect directly with 
the IBC network. 

823
00:48:12,760 --> 00:48:16,240
However, we are working on our 
monomer framework, so if you do 

824
00:48:16,240 --> 00:48:19,520
have a Cosmos SDK roll up that 
natively implements IBC, 

825
00:48:19,760 --> 00:48:22,360
technically that that roll up 
could communicate directly with 

826
00:48:22,360 --> 00:48:25,760
the IBC network. 
So yeah, let's let's talk about 

827
00:48:25,760 --> 00:48:29,480
monomer a little bit. 
So, so monomer is an is an SDKI 

828
00:48:29,480 --> 00:48:35,600
guess the Polymer hub uses 
monomer, but you can also build 

829
00:48:35,600 --> 00:48:40,480
your own roll up using monomer. 
It's I guess a generic roll up 

830
00:48:41,040 --> 00:48:45,120
SDK that uses the OP stack. 
You know, who do you think what 

831
00:48:45,120 --> 00:48:49,640
what kind of applications do you
think will use monomer and what 

832
00:48:49,640 --> 00:48:53,960
is the kind of differentiating 
factor, you know, as opposed to 

833
00:48:53,960 --> 00:48:56,360
using like some of the roll up 
framework or you know, using the

834
00:48:56,400 --> 00:48:58,680
OP stack or something like that?
Yeah. 

835
00:48:58,680 --> 00:49:03,680
So the way I would describe 
this, and I'm, I'm going to use 

836
00:49:03,680 --> 00:49:06,480
an analogy here, I'm going to, 
I'm going to use a cooking 

837
00:49:06,480 --> 00:49:09,480
analogy, even though I'm I'm not
the greatest chef in the world. 

838
00:49:10,560 --> 00:49:12,600
I love cookies. 
It's awesome. 

839
00:49:13,840 --> 00:49:17,040
Little known fact in during the 
COVID, during the pandemic, I 

840
00:49:17,040 --> 00:49:19,600
spent like six months trying to 
perfect the perfect chocolate 

841
00:49:19,600 --> 00:49:22,600
chip cookie because I wanted to 
build a business. 

842
00:49:22,720 --> 00:49:26,040
Oh wow, where you could buy your
cookies fresh on the oven? 

843
00:49:27,400 --> 00:49:32,440
But then I went back to crypto. 
I mean that, that, that I love 

844
00:49:32,440 --> 00:49:36,920
cookies that, that, that sounds,
that sounds very tasty and like 

845
00:49:36,920 --> 00:49:38,880
a like a very interesting 
service. 

846
00:49:39,440 --> 00:49:43,040
So I guess from a, a monomer and
to compare it to be like the 

847
00:49:43,360 --> 00:49:45,760
like built or cooking with the 
cooking with monomer or cooking 

848
00:49:45,760 --> 00:49:49,640
with the monomer and the Cosmos 
SDK versus cooking with the just

849
00:49:49,640 --> 00:49:54,120
the OP stack today. 
It's what you have in your 

850
00:49:54,120 --> 00:49:56,800
kitchen cabinet. 
So if you were to cook with the 

851
00:49:56,800 --> 00:50:00,520
OP stack today, you have the 
EDM, you have like this a 

852
00:50:00,520 --> 00:50:04,000
limited set of ingredients in 
your, in your, in your, in your 

853
00:50:04,200 --> 00:50:06,560
kitchen cabinet. 
And maybe it's just like a salt,

854
00:50:06,560 --> 00:50:11,040
pepper oil, like very, very 
basic ingredients. 

855
00:50:12,160 --> 00:50:14,600
The OP stack doesn't come with a
lot of custom modules and they 

856
00:50:14,600 --> 00:50:18,600
don't have like this like huge 
library of custom modules that 

857
00:50:18,600 --> 00:50:21,960
you can just like pull and, and 
use within your, your app chain.

858
00:50:21,960 --> 00:50:24,520
So it's very hard to customize. 
You can customize it, but you 

859
00:50:24,520 --> 00:50:25,720
have to make your own 
ingredients. 

860
00:50:25,720 --> 00:50:29,080
So like, if you want, I don't 
know, fish stock, you have to go

861
00:50:29,080 --> 00:50:31,240
make your own fish stock and 
then add it to your. 

862
00:50:31,400 --> 00:50:33,760
And like, making fish stock is a
lot harder than just having 

863
00:50:34,120 --> 00:50:36,320
powdered fish stock in your in 
your kitchen cabinet. 

864
00:50:36,920 --> 00:50:39,720
And if you're cooking with the 
Cosmos SEK and modern rare, what

865
00:50:39,720 --> 00:50:42,320
you have is you have this like 
great kitchen cabinet full of 

866
00:50:42,320 --> 00:50:46,160
ingredients, everything ranging 
from a different spices to 

867
00:50:46,160 --> 00:50:51,960
fennel to different herbs to 
different to, to different 

868
00:50:51,960 --> 00:50:55,040
types, even different types of 
salt, like Himalayan salt, like 

869
00:50:55,080 --> 00:50:57,600
all, all the different colors 
there. 

870
00:50:57,880 --> 00:51:01,160
So, and you get this because 
there's a number of teams 

871
00:51:01,160 --> 00:51:03,840
building in the Cosmos SDK. 
There's already this great 

872
00:51:03,840 --> 00:51:06,600
collection of Cosmos SDK modules
that you can just use off the 

873
00:51:06,600 --> 00:51:08,920
shelf. 
So you can build something a 

874
00:51:08,920 --> 00:51:12,440
really cool custom app chain 
without needing to make these 

875
00:51:12,440 --> 00:51:15,000
ingredients yourself. 
And maybe a great example of 

876
00:51:15,000 --> 00:51:18,880
this is Skip's Slinky protocol. 
So you could have this built in 

877
00:51:18,880 --> 00:51:23,000
Oracle directly into your app 
chain without having to like 

878
00:51:23,320 --> 00:51:27,760
like negotiate a contract with 
chain link and and like get 

879
00:51:27,960 --> 00:51:31,360
these price fees at much lower 
latencies and a broader 

880
00:51:31,640 --> 00:51:34,680
selection of prices and also 
custom price fees as well in in 

881
00:51:34,680 --> 00:51:38,200
in a simple way. 
Another example is recently did 

882
00:51:38,200 --> 00:51:40,560
a little bit of announcement 
with Fairblock. 

883
00:51:41,000 --> 00:51:44,000
Fairblock has an encryption 
module for the Cosmos SDK that 

884
00:51:44,000 --> 00:51:47,920
allows you to have encryption 
and decryption or pre execution 

885
00:51:47,920 --> 00:51:50,640
Privacy is what they call it in 
your application. 

886
00:51:50,640 --> 00:51:56,320
So you can have like MEV 
protection, you can have like 

887
00:51:56,360 --> 00:51:59,840
encrypted limit orders, lower 
encrypted mimpole for these like

888
00:52:00,200 --> 00:52:03,720
decks or defy applications. 
And that's hugely beneficial for

889
00:52:04,120 --> 00:52:07,480
a large class of different apps.
Yeah, OK. 

890
00:52:07,520 --> 00:52:08,400
I mean, I mean, that makes 
sense. 

891
00:52:08,400 --> 00:52:13,320
So essentially like what you're 
saying is, you know, monomer 

892
00:52:13,480 --> 00:52:16,640
gives you the benefit of being 
able to use the Cosmos SDK, all 

893
00:52:16,640 --> 00:52:24,360
its modules, but have that roll 
up settle to Etherium, which 

894
00:52:24,360 --> 00:52:27,080
gives you you know which which 
gives you access to a theorem 

895
00:52:27,080 --> 00:52:29,840
with the quiddity gives you 
access to that whole ecosystem 

896
00:52:29,840 --> 00:52:36,040
of of applications. 
Does monomer allow developers 

897
00:52:36,040 --> 00:52:41,280
like is, is monomer opinionated 
about like DA and and settlement

898
00:52:41,280 --> 00:52:45,440
and sequencing? 
Or can developers choose, you 

899
00:52:45,440 --> 00:52:49,880
know, if, if they want to use 
like Eigen DA or Celestia or 

900
00:52:49,880 --> 00:52:52,920
some other DA instead of using a
theorem, data availability, can 

901
00:52:52,920 --> 00:52:54,640
they, can they swap that out 
easily? 

902
00:52:54,920 --> 00:52:58,200
You know, if they want to 
implement their own sequencer, 

903
00:52:59,320 --> 00:53:01,320
is that something that's 
possible or like use some 

904
00:53:01,320 --> 00:53:04,160
decentralized shared sequencer? 
Yes. 

905
00:53:04,160 --> 00:53:09,000
So Modern inherits all of these 
architectural components from 

906
00:53:09,000 --> 00:53:13,720
the OP stack, which is a a 
benefit because any support for 

907
00:53:13,720 --> 00:53:16,880
alternative DA, support for 
fraud proofs, different fraud 

908
00:53:16,880 --> 00:53:21,720
proving mechanisms, forced exit 
mechanisms, forced withdrawal 

909
00:53:21,720 --> 00:53:24,920
mechanisms or forcing the 
transaction inclusion 

910
00:53:24,920 --> 00:53:28,000
mechanisms, these are all 
sourced from the OP stack 

911
00:53:28,040 --> 00:53:30,400
itself. 
So one of the design goals for 

912
00:53:30,400 --> 00:53:33,120
Monomer is that we don't want to
rewrite all this chain 

913
00:53:33,120 --> 00:53:36,440
derivation logic and settlement 
logic, which is quite 

914
00:53:36,440 --> 00:53:40,560
complicated. 
We want to rely on this open 

915
00:53:40,560 --> 00:53:45,040
source community built 
infrastructure that will improve

916
00:53:45,040 --> 00:53:47,720
over time. 
So with OP stack, there are 

917
00:53:47,720 --> 00:53:51,680
modifications to use LDAI 
believe there may be some 

918
00:53:51,680 --> 00:53:55,080
modifications to use different. 
I guess people are calling them 

919
00:53:55,080 --> 00:54:00,960
super builders now, so there's a
lot of these kind of modified or

920
00:54:01,200 --> 00:54:03,640
OP stack modifications that 
developers will be able to 

921
00:54:03,640 --> 00:54:07,160
leverage. 
Like is is the goal here to 

922
00:54:07,160 --> 00:54:10,680
build an ecosystem of 
applications that, you know, use

923
00:54:11,080 --> 00:54:15,160
monomer in the Cosmos SDK And 
like, you know, how do you see 

924
00:54:15,160 --> 00:54:19,120
monomer fairing against, you 
know, some of the other Cosmos 

925
00:54:19,120 --> 00:54:24,440
SDK frameworks out there? 
You know, ethos is 1. 

926
00:54:24,440 --> 00:54:29,520
You know that like utilizes 
Eigen DA or that utilizes Eigen 

927
00:54:29,520 --> 00:54:34,040
layer restaking. 
You know, we have now like I 

928
00:54:34,040 --> 00:54:37,880
guess it's now it's called Grug 
Larry's project Cosmos and 

929
00:54:37,880 --> 00:54:40,200
demon. 
You know, there's like layer 

930
00:54:40,200 --> 00:54:44,400
like Jake Hartnell's project 
that also uses like more more 

931
00:54:44,440 --> 00:54:47,080
uses Cosmos, I might say more so
than the Cosmos SDK. 

932
00:54:47,080 --> 00:54:50,520
But is the future of Cosmos 
development? 

933
00:54:51,680 --> 00:54:55,000
Does it lie in the Cosmos SDK or
does it, do you think, do you 

934
00:54:55,000 --> 00:54:58,600
think that Cosmos and can 
surpass it as a more flexible? 

935
00:54:58,640 --> 00:55:01,200
Because I, I've talked to a lot 
of developers that, you know, 

936
00:55:01,200 --> 00:55:03,080
love the Cosmos SDK because it's
great. 

937
00:55:03,080 --> 00:55:05,760
It has all these modules and 
everything, but also kind of 

938
00:55:05,760 --> 00:55:09,000
hate it because it's so hard to 
build new modules and, you know,

939
00:55:09,000 --> 00:55:13,920
go it, it makes it like a, 
there's like, like a lot of 

940
00:55:13,920 --> 00:55:17,720
configurations to, you know, 
for, for modules, whereas 

941
00:55:17,720 --> 00:55:20,960
building, you know, natively 
with Cosmos is a lot easier. 

942
00:55:20,960 --> 00:55:23,600
And you know, Osmosis, of 
course, I was like built most of

943
00:55:23,600 --> 00:55:25,960
their infrastructure using 
Cosmosmosm. 

944
00:55:26,840 --> 00:55:29,720
Yeah, like do do you see 
Kazumwasum perhaps you know, 

945
00:55:29,720 --> 00:55:35,480
surpassing the SDK itself as you
know a scalable and kind of 

946
00:55:35,920 --> 00:55:37,640
faster way to build 
applications? 

947
00:55:39,400 --> 00:55:43,680
Like with any sort of like VM 
and building for that VM versus 

948
00:55:43,680 --> 00:55:47,080
just building in like like 
native Go or some native runtime

949
00:55:47,480 --> 00:55:50,240
of a particular language, there 
are inherent trade-offs. 

950
00:55:50,240 --> 00:55:54,600
I think the applications will 
decide like what fits best for 

951
00:55:54,600 --> 00:55:58,600
them. 
My hunch is that when they want 

952
00:55:58,600 --> 00:56:01,960
to hit a particular scale or 
when they want to build 

953
00:56:01,960 --> 00:56:06,400
something very specific, perhaps
they will select the Cosmos SDK 

954
00:56:07,400 --> 00:56:11,680
like coming from like Web 2 like
myself, I pick the Cosmos SDK 

955
00:56:11,680 --> 00:56:15,640
because it's maybe the analogy 
here is it's the closest thing 

956
00:56:15,640 --> 00:56:18,840
to React for blog building a 
blockchain that I could find. 

957
00:56:19,320 --> 00:56:21,360
The docs are incredible. 
The support, the tooling is 

958
00:56:21,360 --> 00:56:24,360
incredible. 
There's a lot of momentum behind

959
00:56:24,360 --> 00:56:26,680
this project like binary 
builders is great, Marco is 

960
00:56:26,680 --> 00:56:29,840
great. 
So I I am very bullish on the 

961
00:56:29,840 --> 00:56:31,960
Cosmos SDK. 
But ultimately I think it'll 

962
00:56:31,960 --> 00:56:35,680
come down to if they just want 
to build an application in to 

963
00:56:35,680 --> 00:56:37,720
get something out the door. 
I think they probably are better

964
00:56:37,720 --> 00:56:41,480
off starting with Cosmos and or 
some like existing VM and 

965
00:56:41,480 --> 00:56:42,960
perhaps not even building in 
their own chain. 

966
00:56:42,960 --> 00:56:46,200
Just deploy some smart contracts
through some existing blockchain

967
00:56:46,200 --> 00:56:49,520
network. 
Yeah, that makes sense. 

968
00:56:50,080 --> 00:56:52,240
Yeah. 
Like compared to some of these 

969
00:56:52,240 --> 00:56:56,560
other, you know, Cosmos SDK 
frameworks, why would someone 

970
00:56:56,560 --> 00:57:02,560
choose monomer over say like, 
you know, ethos for example, you

971
00:57:02,560 --> 00:57:05,440
know, like? 
Oh, before I talk about that, I 

972
00:57:05,440 --> 00:57:07,520
didn't want to add 1 point to 
this. 

973
00:57:07,520 --> 00:57:11,120
This, this scaling and I guess 
control the question of control.

974
00:57:11,120 --> 00:57:13,680
So if you use something like 
Cosmos and you don't have 

975
00:57:13,680 --> 00:57:19,720
hardware level control, if you 
use or like I guess kernel level

976
00:57:19,720 --> 00:57:24,320
control for certain applications
that they want to be fast or 

977
00:57:24,320 --> 00:57:27,200
they want to like make certain 
optimizations, they won't want 

978
00:57:27,200 --> 00:57:28,760
that level of control. 
They kind of have to break the 

979
00:57:28,760 --> 00:57:31,760
abstraction boundary. 
But that's not for every 

980
00:57:31,760 --> 00:57:34,320
application. 
I think only a few applications 

981
00:57:34,320 --> 00:57:37,760
will will want that or will feel
like at a certain scale they'll 

982
00:57:37,760 --> 00:57:41,040
want that. 
But yeah, it's, it just, it 

983
00:57:41,040 --> 00:57:44,640
depends on the, the app from a 
framework perspective. 

984
00:57:45,080 --> 00:57:48,320
A lot of the frameworks that you
listed I believe are like like 

985
00:57:48,320 --> 00:57:52,760
Ethos that's providing like I 
can layer restake security for 

986
00:57:52,840 --> 00:57:56,760
like Cosmos chains. 
Those are still technically 

987
00:57:56,760 --> 00:57:59,280
layer ones, even though they get
their security from somewhere 

988
00:57:59,280 --> 00:58:01,000
else. 
They're not technically a layer 

989
00:58:01,000 --> 00:58:04,320
2. 
The cost of security is you're 

990
00:58:04,320 --> 00:58:07,320
paying for security budget 
versus paying for settlement 

991
00:58:07,320 --> 00:58:11,080
costs, which is a layer 2 
consideration and also the 

992
00:58:11,560 --> 00:58:14,560
architecture of your chain. 
You're not inheriting censorship

993
00:58:14,560 --> 00:58:16,680
resistance. 
You're not inheriting some of 

994
00:58:16,680 --> 00:58:20,200
these blockchain properties from
the layer one. 

995
00:58:20,680 --> 00:58:22,800
And some of these blockchain 
properties are some of the 

996
00:58:22,800 --> 00:58:24,720
hardest to achieve. 
Like censorship resistance is 

997
00:58:24,720 --> 00:58:29,440
probably the most difficult when
combined with liveness to 

998
00:58:29,440 --> 00:58:32,320
achieve properties to achieve 
within within blockchain. 

999
00:58:32,320 --> 00:58:36,400
So it depends on what the 
application cares about. 

1000
00:58:36,640 --> 00:58:38,160
If they don't care about 
censorship resistance, they 

1001
00:58:38,160 --> 00:58:40,640
don't care about these 
fundamental blockchain 

1002
00:58:40,640 --> 00:58:43,400
properties. 
They just want to have some like

1003
00:58:43,400 --> 00:58:46,120
security budget they borrow make
that makes a lot of sense. 

1004
00:58:47,080 --> 00:58:49,120
So it depends on what what 
they're, what they're looking 

1005
00:58:49,120 --> 00:58:51,520
for. 
OK. 

1006
00:58:51,560 --> 00:58:52,640
Yeah, thanks for clearing that 
up. 

1007
00:58:52,640 --> 00:58:56,360
OK. 
So like Monomer is squarely A 

1008
00:58:56,360 --> 00:58:59,840
roll up framework and so 
therefore it inherits all the 

1009
00:58:59,840 --> 00:59:02,040
properties of a roll up. 
Whereas like some of these other

1010
00:59:02,040 --> 00:59:05,400
frameworks may be still 
considered like an app chain 

1011
00:59:05,400 --> 00:59:08,920
framework or at least inheriting
it's security from in case of 

1012
00:59:08,920 --> 00:59:13,920
ethos like restaking restate ETH
in the case of you know, 

1013
00:59:13,960 --> 00:59:16,920
building on the Cosmos Hub, like
you're inheriting security from 

1014
00:59:16,920 --> 00:59:17,680
the hub. 
Yeah. 

1015
00:59:19,080 --> 00:59:23,200
And also you're, you're making a
bet on on the technology like 

1016
00:59:23,200 --> 00:59:26,200
when. 
So I guess to give some insight 

1017
00:59:26,200 --> 00:59:29,760
into how we thought about 
technology at a company like 

1018
00:59:29,760 --> 00:59:33,760
Uber when we decided on, you 
know, using a particular 

1019
00:59:33,760 --> 00:59:37,200
database technology, building 
our own, we're taking a long 

1020
00:59:37,200 --> 00:59:40,920
term bet at Uber size and scale.
It's very hard to change course.

1021
00:59:41,440 --> 00:59:45,000
Like moving to a new database 
system is very costly for the 

1022
00:59:45,000 --> 00:59:49,000
entire company. 
So the way we would evaluate is 

1023
00:59:49,000 --> 00:59:52,280
we look on like a 10 year time 
horizon, maybe even 20 year time

1024
00:59:52,280 --> 00:59:54,640
horizon. 
And we have to look at things 

1025
00:59:54,640 --> 00:59:57,200
like, do we think this 
technology that we're building 

1026
00:59:57,200 --> 00:59:59,320
on will continue to improve and 
scale? 

1027
01:00:00,360 --> 01:00:04,280
For the next 10 years, what 
about who are the contributors? 

1028
01:00:05,400 --> 01:00:08,480
What is the pace of development 
in this project? 

1029
01:00:09,760 --> 01:00:11,720
Which direction are they going 
in what, what are they 

1030
01:00:11,760 --> 01:00:13,880
optimizing for? 
How customizable is this? 

1031
01:00:14,200 --> 01:00:15,840
There's all these questions that
you want to answer. 

1032
01:00:16,320 --> 01:00:20,240
And if you bet on Monomer, 
essentially you're betting on a 

1033
01:00:20,240 --> 01:00:21,440
number of different 
technologies. 

1034
01:00:21,440 --> 01:00:26,040
You're betting on there to be a 
great application frameworks 

1035
01:00:26,040 --> 01:00:28,560
that are ABCI compatible, 
whether that's Cosmos SDK, 

1036
01:00:28,560 --> 01:00:32,200
whether that's another framework
such as Grug, you're making a 

1037
01:00:32,200 --> 01:00:34,040
bet there. 
You're also betting on the OP 

1038
01:00:34,040 --> 01:00:35,800
stack. 
You're betting that there will 

1039
01:00:35,800 --> 01:00:39,120
be a continue to be a lot of 
contributors to OP stack and the

1040
01:00:39,120 --> 01:00:41,840
OP stack will continue to 
improve for the next 10 years or

1041
01:00:41,840 --> 01:00:45,280
more. 
So depending on how you look at 

1042
01:00:45,400 --> 01:00:48,280
the space and how you look at 
technology, you'll pick a 

1043
01:00:48,280 --> 01:00:51,800
framework based on like what you
want to bet on long term. 

1044
01:00:52,280 --> 01:00:55,120
Because if you pick a framework 
that perhaps you always 

1045
01:00:55,120 --> 01:00:57,680
maintained by one party or one 
or two parties and that 

1046
01:00:57,680 --> 01:01:01,320
maintenance gets dropped, then 
you're kind of stuck maintaining

1047
01:01:01,320 --> 01:01:03,680
this thing on your own. 
And it's not a great position to

1048
01:01:03,680 --> 01:01:07,680
be in. 
So what's the, what's the next 

1049
01:01:07,680 --> 01:01:11,000
steps here like of, yeah, 
mainnet. 

1050
01:01:11,040 --> 01:01:16,760
And where can people follow you 
and follow Polymer updates to 

1051
01:01:17,680 --> 01:01:19,640
get the latest on what's 
happening with protocol? 

1052
01:01:19,640 --> 01:01:22,040
Yeah, So definitely follow us on
Twitter. 

1053
01:01:22,320 --> 01:01:26,840
It's Polymer under score Labs. 
We have our website and Discord 

1054
01:01:26,840 --> 01:01:29,360
information in there as well for
the for folks that want to join 

1055
01:01:29,360 --> 01:01:32,320
our community. 
You can follow me personally at 

1056
01:01:32,720 --> 01:01:37,320
0X Shake on, on, on Twitter or I
guess Zieder now. 

1057
01:01:37,400 --> 01:01:40,800
It's since, since the since the 
rebrand. 

1058
01:01:42,200 --> 01:01:43,920
But yeah, like maybe it's coming
very soon. 

1059
01:01:44,040 --> 01:01:47,040
I can't give an exact date, but 
I promise you it is, it is, it 

1060
01:01:47,040 --> 01:01:48,800
is coming. 
It is coming very soon. 

1061
01:01:49,800 --> 01:01:52,720
And they'll look out for a lot 
of updates in the in the in the 

1062
01:01:52,720 --> 01:01:55,040
coming months. 
Cool. 

1063
01:01:55,040 --> 01:01:59,360
Well, I'm excited for it. 
A really big fan of what you 

1064
01:01:59,360 --> 01:02:02,360
guys are doing. 
And I think, you know, bringing 

1065
01:02:02,360 --> 01:02:04,760
interoperability, like better 
interoperability between Cosmos 

1066
01:02:04,760 --> 01:02:08,160
and Ethereum is something that 
I've been waiting for, for a 

1067
01:02:08,160 --> 01:02:13,280
long time and like very bullish 
on like that space generally. 

1068
01:02:13,280 --> 01:02:16,440
And yeah, excited to see you 
guys going to main that. 

1069
01:02:16,960 --> 01:02:17,440
Yeah, I think so.