1
00:00:00,000 --> 00:00:18,480
Hello and welcome to episode number 19 of the Awesome Algo podcast.

2
00:00:18,480 --> 00:00:23,840
We have a very special and anonymous guest today.

3
00:00:23,840 --> 00:00:30,840
His name is Bit and he is from a T13 collective, which was originally, I assume, designed as

4
00:00:30,840 --> 00:00:36,540
a collective of developers and enthusiasts building projects on the Algorand blockchain

5
00:00:36,540 --> 00:00:44,640
and generally organizing and performing a lot of different useful activities in the

6
00:00:44,640 --> 00:00:45,640
ecosystem.

7
00:00:45,640 --> 00:00:50,000
And let's say we have a rather packed agenda today with a variety of interesting topics

8
00:00:50,000 --> 00:00:57,280
that we hopefully can cover in time and this will pretty much include things like discussions

9
00:00:57,280 --> 00:01:05,720
and thoughts from Bit in regards to the consensus incentives, things that are currently happening

10
00:01:05,720 --> 00:01:14,400
in terms of shift towards peer-to-peer and I guess potentially and eventually removing

11
00:01:14,400 --> 00:01:20,000
the reliance on the relay nodes, which is one of the, I guess, and used to be for a

12
00:01:20,000 --> 00:01:26,160
long time, one of the main, I guess, arguments against centralization in general in Algorand

13
00:01:26,160 --> 00:01:32,560
blockchain and then some interesting projects that D13 is working himself and some interesting

14
00:01:32,560 --> 00:01:35,760
advanced use cases for box storage.

15
00:01:35,760 --> 00:01:41,760
And on the closing thoughts, we will try to speculate a bit, hopefully in a positive manner

16
00:01:41,760 --> 00:01:46,760
in this very, I'd say, bearish end of the year in regards to the future of Web3.

17
00:01:46,760 --> 00:01:52,720
If you had any questions to D13, you had this opportunity on the askosamalgo.com website

18
00:01:52,720 --> 00:01:57,920
where you can for free ask a question on chain and I think we have a few that we will try

19
00:01:57,920 --> 00:02:00,640
to cover at the very end of the episode.

20
00:02:00,640 --> 00:02:04,960
And with that, once again, D13, thank you very much for coming to this podcast.

21
00:02:04,960 --> 00:02:06,680
I've been following your work.

22
00:02:06,680 --> 00:02:12,240
I think you are doing amazing contributions to the ecosystem and you're always there whenever

23
00:02:12,240 --> 00:02:17,120
there is a major event or whenever there is some interesting ways of covering the latest

24
00:02:17,120 --> 00:02:19,480
features in the Algorand blockchain.

25
00:02:19,480 --> 00:02:26,680
And it's just, you're one of the engineers and generally people in the ecosystem who,

26
00:02:26,680 --> 00:02:33,080
I think, just inspires people to come and build on this particular network.

27
00:02:33,080 --> 00:02:39,600
And with that, I think the stage is yours and would love to start with, as we usually

28
00:02:39,600 --> 00:02:43,960
do with this podcast, when we get guests who are from engineering backgrounds, if we could

29
00:02:43,960 --> 00:02:48,720
just cover a little bit on your academic and professional background.

30
00:02:48,720 --> 00:02:54,680
And I understand in regards to the anonymity aspects of it, you can skip certain parts

31
00:02:54,680 --> 00:02:57,600
of it, but we could maybe start with...

32
00:02:57,600 --> 00:02:59,080
We'll paint in broad strokes.

33
00:02:59,080 --> 00:03:03,200
So first of all, it's my genuine pleasure and honor to be here.

34
00:03:03,200 --> 00:03:05,360
Your podcast is one of my favorites.

35
00:03:05,360 --> 00:03:12,480
I'm massively into podcasts anyway, but whenever there's a new awesome Algorand, it's at the

36
00:03:12,480 --> 00:03:15,960
top of the to listen to list.

37
00:03:15,960 --> 00:03:18,760
So my pleasure and what an intro.

38
00:03:18,760 --> 00:03:21,520
Honestly, I got goosebumps at some point during that.

39
00:03:21,520 --> 00:03:22,760
So thank you very much.

40
00:03:22,760 --> 00:03:25,640
Yeah, a little bit about Young Bit.

41
00:03:25,640 --> 00:03:30,920
I got into technology very, very young before it was fashionable even.

42
00:03:30,920 --> 00:03:36,400
And I was a little bit of the stereotypical anti-social kid who was just fascinated by

43
00:03:36,400 --> 00:03:42,760
this box that ran Windows 95 and it had infinite depth and allowed you to delete files from

44
00:03:42,760 --> 00:03:46,320
System 32 and then build it up from scratch again.

45
00:03:46,320 --> 00:03:52,680
And yeah, I think my first foray into programming was building a webpage.

46
00:03:52,680 --> 00:03:56,480
I actually didn't have a hobby aside from my computer and so I borrowed a hobby from

47
00:03:56,480 --> 00:03:57,480
a friend.

48
00:03:57,480 --> 00:03:59,960
He was big into tractors for some reason.

49
00:03:59,960 --> 00:04:04,400
And so we made a website about tractors, just HTML, right?

50
00:04:04,400 --> 00:04:06,040
Which is not a programming language, right?

51
00:04:06,040 --> 00:04:07,480
It's a markup, but okay.

52
00:04:07,480 --> 00:04:08,880
So that was my first experience.

53
00:04:08,880 --> 00:04:15,760
And then I think the first actual programming language was PHP and I kind of got into it

54
00:04:15,760 --> 00:04:17,800
from that.

55
00:04:17,800 --> 00:04:25,560
And academically, I also studied in the field.

56
00:04:25,560 --> 00:04:30,240
My mom wanted me to be a computer scientist, but I ended up as a web developer, you know,

57
00:04:30,240 --> 00:04:32,280
unless there's appointment.

58
00:04:32,280 --> 00:04:33,720
Right.

59
00:04:33,720 --> 00:04:41,000
So yeah, I'm a software developer in real life, mostly around the web stack.

60
00:04:41,000 --> 00:04:46,800
And yeah, the premise of blockchain and web three in general, especially from the second

61
00:04:46,800 --> 00:04:51,520
generation of blockchains on where you can actually do stuff aside from send coins to

62
00:04:51,520 --> 00:04:52,520
one another.

63
00:04:52,520 --> 00:04:55,960
There's something really, really exciting about this.

64
00:04:55,960 --> 00:05:00,200
I'm not sure if the cypherpunk dream is completely dead yet.

65
00:05:00,200 --> 00:05:03,080
I think that some people are still fighting for it.

66
00:05:03,080 --> 00:05:09,080
Yeah, but that's one of the things that excites me about this space.

67
00:05:09,080 --> 00:05:15,480
Maybe if we can expand a little bit on the excitement part about the blockchain and the

68
00:05:15,480 --> 00:05:21,840
web three in general, like I know there is, I would say the learning curve maybe to do

69
00:05:21,840 --> 00:05:29,440
the transition from engineering, I would say background where you're dealing with web development

70
00:05:29,440 --> 00:05:36,960
in general into web three is usually easier for some people considering the dominance

71
00:05:36,960 --> 00:05:43,480
of things like JavaScript and TypeScript in the general like broad scope of the tooling.

72
00:05:43,480 --> 00:05:48,360
If you look on, for example, Ethereum or any other bigger ecosystems, which makes sense,

73
00:05:48,360 --> 00:05:52,000
I assume this also comes from the adoption aspects.

74
00:05:52,000 --> 00:05:56,880
People are trying to attract engineers and often looking at the maybe languages or the

75
00:05:56,880 --> 00:06:00,600
technologies that has the most people working on it.

76
00:06:00,600 --> 00:06:03,000
And there's a lot of people in web development in general.

77
00:06:03,000 --> 00:06:11,000
But what really just initially got you fascinated with distributed systems, fault tolerant systems

78
00:06:11,000 --> 00:06:13,840
and blockchain technology in general?

79
00:06:13,840 --> 00:06:19,120
That would have been before Bitcoin was even a thing during my studies.

80
00:06:19,120 --> 00:06:22,240
Let's say that I'm mid to late 30s.

81
00:06:22,240 --> 00:06:28,360
So the challenges of distributed systems was something that always looked like a really

82
00:06:28,360 --> 00:06:33,760
interesting challenge with many elegant and some non-elegant solutions.

83
00:06:33,760 --> 00:06:41,480
So the entire Byzantine general fault tolerance situation, how to have a consensus that can

84
00:06:41,480 --> 00:06:46,360
carry on even in the presence of an almost majority of malicious actors.

85
00:06:46,360 --> 00:06:49,480
I mean, that's kind of fascinating, right?

86
00:06:49,480 --> 00:06:53,760
Generally with blockchain specifically, I got in fairly early.

87
00:06:53,760 --> 00:07:01,260
So I was early in Bitcoin and it was just fascinating to think that a community can

88
00:07:01,260 --> 00:07:07,920
make something that's valuable, that's recognized as money without being given permission, so

89
00:07:07,920 --> 00:07:08,920
to speak.

90
00:07:08,920 --> 00:07:13,880
The financial system is still massively gated and permissioned.

91
00:07:13,880 --> 00:07:19,480
There are easy ways for you to get started with Stripe or PayPal or something, but then

92
00:07:19,480 --> 00:07:23,960
your access to that can be yanked in a second.

93
00:07:23,960 --> 00:07:30,960
And then you're stuck speaking to customer support agents who are following and anti-spammer

94
00:07:30,960 --> 00:07:32,440
and scammer script.

95
00:07:32,440 --> 00:07:39,120
And here you are with your business trying to figure out why you can't process payments.

96
00:07:39,120 --> 00:07:43,640
So that's one of the things that drew me to the early Bitcoin days.

97
00:07:43,640 --> 00:07:50,080
I didn't really think it would be particularly successful, but still I was down to try it.

98
00:07:50,080 --> 00:07:52,320
I got a friend excited about this as well.

99
00:07:52,320 --> 00:07:57,280
And we built some custom rigs with GPUs to actually mine a little bit of Bitcoin.

100
00:07:57,280 --> 00:08:00,920
The first priority as rational economic actors was to pay off the rig.

101
00:08:00,920 --> 00:08:02,820
Am I regretting that now?

102
00:08:02,820 --> 00:08:07,600
But I did successfully pay off the rig and then I had a few satoshis left over.

103
00:08:07,600 --> 00:08:14,660
But from a development point of view, I'm not sure what much there was to create back

104
00:08:14,660 --> 00:08:22,200
then aside from maybe a mining pool or a payment processor to just send or receive Bitcoin.

105
00:08:22,200 --> 00:08:29,600
There wasn't very much more to do and neither of these was something that kind of drew me

106
00:08:29,600 --> 00:08:30,960
to actually code with it.

107
00:08:30,960 --> 00:08:38,400
I was just like a user and for a little while while GPU mining was viable and minor.

108
00:08:38,400 --> 00:08:44,520
And then I've kind of been on and off with the blockchain space since then, but at the

109
00:08:44,520 --> 00:08:52,180
tail end of the last bull run in around November or December of 2021, I was looking around

110
00:08:52,180 --> 00:08:59,920
for, you know, a great blockchain platform that does smart contracts as well.

111
00:08:59,920 --> 00:09:05,180
Because once smart contracts come into the equation, then you could just code what is

112
00:09:05,180 --> 00:09:10,640
effectively an autonomous agent that will be hosted for you forever on the chain.

113
00:09:10,640 --> 00:09:15,600
And if you don't mess up the logic, it might just operate basically forever or as long

114
00:09:15,600 --> 00:09:18,680
as the blockchain is alive.

115
00:09:18,680 --> 00:09:25,720
So I looked at the most popular and some of the up and coming L1s at the tail end of 2021

116
00:09:25,720 --> 00:09:29,800
and Algorand stood out by about a mile.

117
00:09:29,800 --> 00:09:33,060
Like there wasn't a question of going elsewhere.

118
00:09:33,060 --> 00:09:37,460
This is of course coming from a hobbyist perspective, right?

119
00:09:37,460 --> 00:09:41,460
The calculus may have been different if I was, you know, kind of quit my day job and

120
00:09:41,460 --> 00:09:46,400
start a business and try to feed my family and my employees' families out of this.

121
00:09:46,400 --> 00:09:52,320
But my involvement in this space is intentionally not monetized.

122
00:09:52,320 --> 00:09:56,600
And this is basically my hobby and a creative outlet.

123
00:09:56,600 --> 00:10:03,000
But honestly, looking, comparing Algorand to previous generation blockchains like Ethereum

124
00:10:03,000 --> 00:10:12,720
or even contemporary, let's say, competitors, it's just like the brief for creating Algorand

125
00:10:12,720 --> 00:10:18,320
was all right, reconsider absolutely everything about what the blockchain is and how it works

126
00:10:18,320 --> 00:10:24,440
down to the damn addresses and think if we could do this from scratch in the optimal

127
00:10:24,440 --> 00:10:26,840
way, like what would it look like?

128
00:10:26,840 --> 00:10:32,360
The fact that our addresses are base 32 instead of base 16 and they also have a checksum at

129
00:10:32,360 --> 00:10:39,480
the end means that you can't accidentally like fub a single digit or letter and then

130
00:10:39,480 --> 00:10:42,080
send your money into a black hole.

131
00:10:42,080 --> 00:10:44,560
That is brilliant, right?

132
00:10:44,560 --> 00:10:50,720
The fact that we have standard assets and when you buy my token or a token, there's

133
00:10:50,720 --> 00:10:54,760
basically two fields to look at to see if it can be frozen or clawed back and that's

134
00:10:54,760 --> 00:10:55,760
it.

135
00:10:55,760 --> 00:11:02,120
You can trust that it will behave as every other ASA will.

136
00:11:02,120 --> 00:11:11,320
On Ethereum, there are websites that analyze ERC20 codes to see if they are vulnerable

137
00:11:11,320 --> 00:11:16,240
in some known ways, but you can always make it vulnerable in a brand new way.

138
00:11:16,240 --> 00:11:22,080
There was semi-recently a token by an influencer that had a bug in the transfer from that he

139
00:11:22,080 --> 00:11:24,480
later claimed was intentional.

140
00:11:24,480 --> 00:11:31,760
It's a lot more complicated and dangerous than it needs to be and having at least a

141
00:11:31,760 --> 00:11:36,920
base asset being standardized so that you can trust that at least the mechanics of how

142
00:11:36,920 --> 00:11:41,560
it's going to work is going to work exactly as it's advertised.

143
00:11:41,560 --> 00:11:44,680
That's pretty big.

144
00:11:44,680 --> 00:11:50,740
If I may ask a side question on this as well, when you were assessing different chains as

145
00:11:50,740 --> 00:11:57,240
you said in the tail end of the bull run in 2021, what were the main criteria by which

146
00:11:57,240 --> 00:11:58,400
you did this assessment?

147
00:11:58,400 --> 00:12:05,880
Was it mostly developer experience where you were approaching this on a more balanced scale

148
00:12:05,880 --> 00:12:10,440
or you would also look at the consensus as well?

149
00:12:10,440 --> 00:12:16,560
Just curious how did you assess the individual L1 chains that were rising in that particular

150
00:12:16,560 --> 00:12:19,520
year to come to the conclusion with Zalgirain?

151
00:12:19,520 --> 00:12:21,680
It was a little bit of everything.

152
00:12:21,680 --> 00:12:24,660
There's the user experience that the chain enables.

153
00:12:24,660 --> 00:12:29,740
There's a developer experience which I guess there's two aspects there at least.

154
00:12:29,740 --> 00:12:34,460
One is how easy it is to get started, but two is how powerful the primitives that are

155
00:12:34,460 --> 00:12:43,680
offered are and so that limits or enables how complicated and the things you can build.

156
00:12:43,680 --> 00:12:50,400
The consensus mechanism I think was a big selling point and not only from the aspect

157
00:12:50,400 --> 00:12:55,360
of elegance but also from the things that it enables.

158
00:12:55,360 --> 00:13:01,320
Having zero second finality and I think it was 3.7 block runtime or it might have been

159
00:13:01,320 --> 00:13:02,320
a little bit more.

160
00:13:02,320 --> 00:13:06,720
Let's say four seconds runtime, so four seconds to finality from the time you submitted your

161
00:13:06,720 --> 00:13:09,400
transaction.

162
00:13:09,400 --> 00:13:13,040
That's basically unheard of still.

163
00:13:13,040 --> 00:13:20,240
Maybe Solana can compete with that, but later on as part of the agenda we'll see how Algorand

164
00:13:20,240 --> 00:13:23,800
is scheduled to evolve with regards to that as well.

165
00:13:23,800 --> 00:13:30,320
Both from a user experience and from a developer experience point of view, being able to forget

166
00:13:30,320 --> 00:13:35,800
completely about deterministic finality and knowing that if it's a block, it's canonical,

167
00:13:35,800 --> 00:13:37,320
it's full stop.

168
00:13:37,320 --> 00:13:38,960
That's pretty great, right?

169
00:13:38,960 --> 00:13:46,560
Otherwise you usually have to wait for a few rounds or blocks and see if it's in the chain

170
00:13:46,560 --> 00:13:51,520
long enough so to speak and then you have an arbitrary length of blocks after which

171
00:13:51,520 --> 00:13:55,960
you consider things to be final.

172
00:13:55,960 --> 00:14:04,640
There's a lot to having almost instant finality as soon as a block is minted.

173
00:14:04,640 --> 00:14:11,240
The smart contract layer as well, you can do almost everything you might want.

174
00:14:11,240 --> 00:14:19,200
I think part of the design has been for performance and throughput and so I think the AVM smart

175
00:14:19,200 --> 00:14:23,520
contract language, Teal or Ask One if you want to call it, I think it's intentionally

176
00:14:23,520 --> 00:14:26,920
restricted in a lot of ways.

177
00:14:26,920 --> 00:14:32,640
Maybe some of that could be lifted a little bit, but yeah, I think it was the overall

178
00:14:32,640 --> 00:14:33,640
package.

179
00:14:33,640 --> 00:14:38,920
And it, I mean, to be frank, went through quite a journey, right?

180
00:14:38,920 --> 00:14:44,520
If you look at the evolution that AVM and the things it was capable of just three, four

181
00:14:44,520 --> 00:14:49,280
years ago and now, the things that you are able to do now, especially with the introduction

182
00:14:49,280 --> 00:14:56,200
of inner transactions and box storage, which is of course, I mean, there's always additional

183
00:14:56,200 --> 00:15:01,440
layers that potentially could be improved in this regard, but it is quite a significant

184
00:15:01,440 --> 00:15:07,160
chunk of things that the guys at Algorand Inc. managed to squash in the past, say, three

185
00:15:07,160 --> 00:15:09,560
years in comparison to the original one.

186
00:15:09,560 --> 00:15:14,400
But if I recall correctly, yes, it's indeed something that had, it didn't have like sort

187
00:15:14,400 --> 00:15:19,840
of extremely ambitious long-term vision in regards to the things that let's put it now.

188
00:15:19,840 --> 00:15:22,480
So of course there's post quantum security, right?

189
00:15:22,480 --> 00:15:29,320
But I think if I recall correctly, the chat I had in the episode two with Zev from Algorand

190
00:15:29,320 --> 00:15:34,740
Inc, they had a very particular set of requirements and it was performance, optimizing for performance

191
00:15:34,740 --> 00:15:41,880
and they sort of started with that and then evolved through taking sort of very careful

192
00:15:41,880 --> 00:15:43,280
considerations in design.

193
00:15:43,280 --> 00:15:51,160
So that is the whole premise and I guess the beauty of it, allowing it to have such a low

194
00:15:51,160 --> 00:15:52,280
finality.

195
00:15:52,280 --> 00:15:58,840
But going further though, now obviously a lot of people got into Algorand development,

196
00:15:58,840 --> 00:16:04,720
maybe if we are talking about engineers who are still building decentralized apps, potentially

197
00:16:04,720 --> 00:16:08,760
as you said, right, the bull run, the tail end, maybe the beginning of the bull run in

198
00:16:08,760 --> 00:16:18,600
2020, 2021 and if you look at the current state of the Algorand ecosystem, I think the

199
00:16:18,600 --> 00:16:27,160
big shift that potentially happened is that original proposal or like the original intent

200
00:16:27,160 --> 00:16:34,360
from Silvio is to buy design, not to have incentives of sorts, right?

201
00:16:34,360 --> 00:16:44,040
Not to have incentives for running the participation nodes, which essentially shifted after I guess

202
00:16:44,040 --> 00:16:52,280
many years of the seeing in practice that we live in a very materialistic world and

203
00:16:52,280 --> 00:16:59,400
despite the great maybe altruistic vision in that, as a step towards further decentralization

204
00:16:59,400 --> 00:17:04,320
but also tackling some of these problems in regards to, okay, how do we actually put some

205
00:17:04,320 --> 00:17:09,320
extra incentive for people to have the participation nodes, to have a reason to run a participation

206
00:17:09,320 --> 00:17:10,320
node, right?

207
00:17:10,320 --> 00:17:19,280
Because it's no longer this simple software that you can just run on the Raspberry Pi

208
00:17:19,280 --> 00:17:22,400
and put somewhere in the corner of your room.

209
00:17:22,400 --> 00:17:27,600
The amount of things that are being added to AVM and just generally into the infrastructure

210
00:17:27,600 --> 00:17:30,720
tooling is increasing the complexity that increases the hardware requirements.

211
00:17:30,720 --> 00:17:36,720
So it's no longer having that advantage of a, I guess, a simpler premise that it takes

212
00:17:36,720 --> 00:17:38,880
less compute power to run it.

213
00:17:38,880 --> 00:17:43,840
So it's sort of at this point, I feel like really comes in as a, as just the natural

214
00:17:43,840 --> 00:17:49,160
part of evolution, which also ties in with what Silvio is originally was planning to

215
00:17:49,160 --> 00:17:54,080
do, which I think every consensus for a good decentralized system should have some notion

216
00:17:54,080 --> 00:17:55,400
of adaptability, right?

217
00:17:55,400 --> 00:18:02,360
You can just have a set of rules that can sustain thousands of years because software

218
00:18:02,360 --> 00:18:06,680
is not like, software is something that degrades over time.

219
00:18:06,680 --> 00:18:11,840
No matter how good it is, there's always going to be something that I think over a large

220
00:18:11,840 --> 00:18:15,880
span of time going to have some maintenance, going to need some maintenance.

221
00:18:15,880 --> 00:18:22,480
So that aspect of adaptability in the consensus is what enables, I guess, this transition

222
00:18:22,480 --> 00:18:23,720
as well.

223
00:18:23,720 --> 00:18:27,840
But I guess making a transition into some of the main topics of the agenda, I wanted

224
00:18:27,840 --> 00:18:33,160
to hear some of your thoughts on the consensus incentives in the ecosystem.

225
00:18:33,160 --> 00:18:37,400
And maybe if you could just do a very short recap for some of the listeners who may not

226
00:18:37,400 --> 00:18:42,080
be aware of the latest state of the discussions in the ecosystem in this regard.

227
00:18:42,080 --> 00:18:50,280
But yeah, what do you think are the main advantages and disadvantages of having consensus incentives

228
00:18:50,280 --> 00:18:51,900
introduced at different levels?

229
00:18:51,900 --> 00:18:58,560
One is, I guess, team, let's have it at the protocol level versus the other one is, okay,

230
00:18:58,560 --> 00:19:05,160
let's have something that maybe resembles the existing consensus programs in the ecosystem

231
00:19:05,160 --> 00:19:07,160
a bit closer.

232
00:19:07,160 --> 00:19:09,400
Yeah, for sure.

233
00:19:09,400 --> 00:19:14,440
First of all, I think that a big part of wisdom is looking at the things that you're trying,

234
00:19:14,440 --> 00:19:19,700
even especially the most ambitious ones, and then realizing that they are not working.

235
00:19:19,700 --> 00:19:28,100
As you said, the original vision for the consensus layer of Algorand was that the requirements

236
00:19:28,100 --> 00:19:33,880
from a hardware point of view were going to be low enough that people would be able to

237
00:19:33,880 --> 00:19:40,400
and glad to run participation nodes without any compensation.

238
00:19:40,400 --> 00:19:44,200
I think this largely failed as an experiment.

239
00:19:44,200 --> 00:19:53,360
The stats speak for themselves and something also, I'm not just saying that from the sidelines,

240
00:19:53,360 --> 00:20:00,280
I guess that too, but I've been fairly prominent in helping people either one-to-one or via

241
00:20:00,280 --> 00:20:07,920
writing guides into how to set up participation nodes for maybe about a year and a half now.

242
00:20:07,920 --> 00:20:18,260
But people are either not able to do so technically, which has started to be addressed by initiatives

243
00:20:18,260 --> 00:20:23,580
like Algorand, like the one-click nodes that the foundation does, and another third-party

244
00:20:23,580 --> 00:20:31,000
one-click node interface called the host one-click node, I think, by host.

245
00:20:31,000 --> 00:20:35,880
That's one aspect is how hard is it to set things up.

246
00:20:35,880 --> 00:20:41,800
For the one-click initiatives, you had to be either fairly well versed in setting up

247
00:20:41,800 --> 00:20:43,840
something usually on Linux.

248
00:20:43,840 --> 00:20:49,920
Now, this is getting easier and it has been getting easier for some time now.

249
00:20:49,920 --> 00:20:54,480
The second part is even if you are able to, would you be willing to do so, especially

250
00:20:54,480 --> 00:21:00,400
considering that you need to park some algo in an account that's not basically getting

251
00:21:00,400 --> 00:21:01,760
any yield?

252
00:21:01,760 --> 00:21:07,720
The shift of governance from generally the governance incentives from the foundation,

253
00:21:07,720 --> 00:21:14,240
if you zoom out a little bit, are transitioning from super passive into a little bit more

254
00:21:14,240 --> 00:21:16,120
involved, a little bit more engaged.

255
00:21:16,120 --> 00:21:21,720
In the early days, if you recall, there were passive rewards where rewards would accumulate

256
00:21:21,720 --> 00:21:24,080
in your account until a certain round.

257
00:21:24,080 --> 00:21:29,800
And then the next time you transacted, your balance could have a little bit of yield based

258
00:21:29,800 --> 00:21:32,600
on your balance.

259
00:21:32,600 --> 00:21:36,480
And then when that stopped, I think it did it.

260
00:21:36,480 --> 00:21:40,440
I'm not sure if it overlapped with the first season of first period of governance or not,

261
00:21:40,440 --> 00:21:48,920
but then during Algorand governance, you basically were incentivized to keep your funds in an

262
00:21:48,920 --> 00:21:52,640
account outside of the DeFi economy.

263
00:21:52,640 --> 00:21:59,240
And so there was a clash of incentives there because people were building decks and lending

264
00:21:59,240 --> 00:22:06,920
and this and that on chain, but they had to compete with, if I recall, 8% APR yield for

265
00:22:06,920 --> 00:22:11,240
not getting involved in your protocol and so on.

266
00:22:11,240 --> 00:22:15,440
And when one of them is custodial and has smart contract risk and all of that, and the

267
00:22:15,440 --> 00:22:23,080
other can be parked on a ledger and it's just appreciates in algo terms, like 8% a year,

268
00:22:23,080 --> 00:22:30,360
the foundation recognized that this setup was stifling the on chain economy and it did

269
00:22:30,360 --> 00:22:33,880
adapt quite well into incentivizing.

270
00:22:33,880 --> 00:22:39,200
First we got some liquid governance protocols and then these were heavily incentivized.

271
00:22:39,200 --> 00:22:45,320
So I believe the APR for vanilla governance right now might be something like 4% and via

272
00:22:45,320 --> 00:22:51,640
DeFi the last period was something like 18, which I believe, I mean, I agree with that,

273
00:22:51,640 --> 00:22:57,000
but it does clash with consensus participation unless you can combine the two.

274
00:22:57,000 --> 00:23:02,560
While we had AlgoFi volts, you could actually combine the two if you were getting rewarded

275
00:23:02,560 --> 00:23:08,840
for participating via AlgoFi anyway, and you wanted to, you could also participate in consensus

276
00:23:08,840 --> 00:23:11,120
via your AlgoFi volt.

277
00:23:11,120 --> 00:23:13,600
False Finance recently also enabled that.

278
00:23:13,600 --> 00:23:21,600
Their V2 model has a personal escrow account that's quite similar to what AlgoFi volts

279
00:23:21,600 --> 00:23:27,040
used to look like, whereas V1 was actually all pulled into a single account and so participation

280
00:23:27,040 --> 00:23:29,680
would not have been possible that way.

281
00:23:29,680 --> 00:23:34,920
And I think that at least in the short term, there are discussions about incentivizing

282
00:23:34,920 --> 00:23:41,160
consensus participation via some kind of governance boost, like the DeFi boost, there could also

283
00:23:41,160 --> 00:23:44,840
be a consensus participation boost.

284
00:23:44,840 --> 00:23:52,840
And personally, I think that is a good idea to at least investigate in the short term.

285
00:23:52,840 --> 00:23:58,920
We also do have a data point to look at and see if something like this is even going to

286
00:23:58,920 --> 00:24:04,760
make a difference, which is False Finance, which ran their own consensus initiative as

287
00:24:04,760 --> 00:24:11,520
a surprise about a week or two after last period's governance commitment ended.

288
00:24:11,520 --> 00:24:17,400
They just announced, if you participate through your folks escrow, you get like your share

289
00:24:17,400 --> 00:24:20,280
of 50,000 Algo.

290
00:24:20,280 --> 00:24:28,800
They didn't have a way to measure eligibility and then participate the rewards and then

291
00:24:28,800 --> 00:24:30,560
distribute the rewards.

292
00:24:30,560 --> 00:24:38,000
And so they said that it's going to be a flat reward of 50k Algo divided by however many.

293
00:24:38,000 --> 00:24:43,520
So they are also doing a similar program for this period.

294
00:24:43,520 --> 00:24:47,960
I think they are allocating something like 70k Algo right now.

295
00:24:47,960 --> 00:24:54,400
And what we can see from that, by the way, one of the things, a small little site that

296
00:24:54,400 --> 00:24:58,480
I've built is called consensus.algorithm.observer.

297
00:24:58,480 --> 00:25:03,800
And if you go there, you're going to see a table that looks very much like the ledger

298
00:25:03,800 --> 00:25:09,400
database table on each Algo D node that includes the number of accounts that have declared

299
00:25:09,400 --> 00:25:13,600
themselves to be online as in participating in consensus.

300
00:25:13,600 --> 00:25:19,280
And I add a few fields there for looking up which ones are Algo 5 volts, rest in peace,

301
00:25:19,280 --> 00:25:22,000
or a False Finance escrow accounts.

302
00:25:22,000 --> 00:25:30,440
And what we can see from that is that there are 131 accounts registered online that are

303
00:25:30,440 --> 00:25:38,600
False Finance escrow accounts out of 335 total online accounts in Algorand consensus.

304
00:25:38,600 --> 00:25:44,880
So taking away a few that have super low balance and might be inactive for a few years now,

305
00:25:44,880 --> 00:25:48,220
which they are, but it doesn't hurt if they don't have any balance.

306
00:25:48,220 --> 00:25:53,400
We are talking about something like 40% by absolute number of participating addresses

307
00:25:53,400 --> 00:25:56,760
being run as part of this program.

308
00:25:56,760 --> 00:26:00,180
Now by absolute stake, the number is a lot lower.

309
00:26:00,180 --> 00:26:06,440
It's actually 22.2 million Algo online through False.

310
00:26:06,440 --> 00:26:13,600
So I think at least in the short term, getting more people involved in running nodes and

311
00:26:13,600 --> 00:26:19,720
in securing the network is something that needs to happen.

312
00:26:19,720 --> 00:26:26,760
The number of participating nodes during the tail end of last year dropped to under maybe

313
00:26:26,760 --> 00:26:28,520
150 or so.

314
00:26:28,520 --> 00:26:32,640
Don't take my word for it, but the consensus numbers dropped significantly.

315
00:26:32,640 --> 00:26:39,520
And then at some point recently, when there were some concerns about an Algorand whale

316
00:26:39,520 --> 00:26:46,560
that I believe turned out, I accept an analysis that showed that it was a Korean exchange

317
00:26:46,560 --> 00:26:49,980
that was accumulating a lot of Algo.

318
00:26:49,980 --> 00:26:55,220
So the analysis that I believe shows that this is one of their wallets.

319
00:26:55,220 --> 00:27:00,760
But around that time, the Algorand Foundation put a lot of their own stake online.

320
00:27:00,760 --> 00:27:07,720
Currently, if you went to consensus.algorand.observer and you filtered by the labels and you added

321
00:27:07,720 --> 00:27:16,360
up all of the foundation labeled addresses, they would add up to 942 million Algo out

322
00:27:16,360 --> 00:27:19,080
of 1.4 billion online.

323
00:27:19,080 --> 00:27:26,800
So by stake, the foundation currently has 67% of the online stake.

324
00:27:26,800 --> 00:27:34,960
And so the consensus incentives, and as we'll talk about later, the shift to peer to peer,

325
00:27:34,960 --> 00:27:41,600
will actually take us from our present state, which is, in my view at least, a protocol

326
00:27:41,600 --> 00:27:46,560
that is decentralizable, but not quite decentralized yet.

327
00:27:46,560 --> 00:27:53,760
Hopefully, consensus incentives, both in the short term and in the longer term, and also

328
00:27:53,760 --> 00:28:02,320
leading the relay nodes is going to help truly decentralize Algorand.

329
00:28:02,320 --> 00:28:04,520
So would you say it's a fair assessment to say that?

330
00:28:04,520 --> 00:28:10,560
And I certainly agree with your point on this regard, but given that there is already protocols

331
00:28:10,560 --> 00:28:16,600
and there are mechanisms in the ecosystem that were built as part of, just generally,

332
00:28:16,600 --> 00:28:20,600
as you said, protocols trying to adjust to the governance models and things like that,

333
00:28:20,600 --> 00:28:27,460
there are already mechanisms in place that I think just pair nicely or could pair nicely

334
00:28:27,460 --> 00:28:32,720
with providing incentives without actually messing with anything at the protocol level.

335
00:28:32,720 --> 00:28:39,880
So I guess continuing, at least experimenting in this regard, should be a good indicator

336
00:28:39,880 --> 00:28:45,920
on whether it does make sense at all to try to perform any changes on the level, which

337
00:28:45,920 --> 00:28:51,400
I assume is already what protocols like folks are doing with the introduction of the incentive

338
00:28:51,400 --> 00:28:57,200
set at the level of their protocol, also playing well with the vanilla governance.

339
00:28:57,200 --> 00:29:03,200
And I'm not sure about ex-Golf completely though, whether it has mechanisms for consensus

340
00:29:03,200 --> 00:29:07,800
participation if you're an ex-Golf member as well though.

341
00:29:07,800 --> 00:29:10,560
They are completely separate concerns.

342
00:29:10,560 --> 00:29:15,400
So yes, you can participate and also be an ex-Golf.

343
00:29:15,400 --> 00:29:16,400
Yeah.

344
00:29:16,400 --> 00:29:19,800
So on that regard...

345
00:29:19,800 --> 00:29:26,780
Yeah, I agree with experimenting with the governance model.

346
00:29:26,780 --> 00:29:34,640
Something else that needs to be solved is how to reward consensus participation.

347
00:29:34,640 --> 00:29:38,520
Wolf's Finance had a question about how they should do it for this period.

348
00:29:38,520 --> 00:29:46,360
And I came up with a way and suggested to them that I believe there should be two different

349
00:29:46,360 --> 00:29:47,360
criteria.

350
00:29:47,360 --> 00:29:52,080
One should be eligibility, whether someone should get rewarded at all, and the other

351
00:29:52,080 --> 00:29:57,200
about how the actual rewards will be distributed, which is a bit more banal.

352
00:29:57,200 --> 00:30:04,440
But the problem is when you're trying to figure out incentives in a consensus protocol that

353
00:30:04,440 --> 00:30:09,720
was not designed with incentives in mind, you need to figure out how you're going to

354
00:30:09,720 --> 00:30:14,760
punish or address those that are participating properly.

355
00:30:14,760 --> 00:30:20,880
And without having any slashing of stake, which is the traditional way of punishing

356
00:30:20,880 --> 00:30:25,680
participation nodes that are not participating properly, then the only thing you have to

357
00:30:25,680 --> 00:30:28,480
take away is the rewards.

358
00:30:28,480 --> 00:30:35,240
And I think doing this in an epoch, so to speak, such as the three months of governance

359
00:30:35,240 --> 00:30:43,000
and looking at your average voting rate over that period is actually a really good way

360
00:30:43,000 --> 00:30:49,320
to filter out those who were participating well enough from those who weren't.

361
00:30:49,320 --> 00:30:54,560
And so after you filtered by that, then the best way to distribute rewards is actually

362
00:30:54,560 --> 00:31:00,640
block production because that is linear to your stake, whereas votes have more of a logarithmic

363
00:31:00,640 --> 00:31:01,640
curve.

364
00:31:01,640 --> 00:31:10,960
And do you think this is something that is in an ideal world, a due diligence of every

365
00:31:10,960 --> 00:31:15,280
protocol or should this be eventually standardized as well?

366
00:31:15,280 --> 00:31:20,320
Maybe it's to be some sort of arc that follows generally?

367
00:31:20,320 --> 00:31:24,680
This is the first time that something like this will be tried on Algorand.

368
00:31:24,680 --> 00:31:31,680
I think it should be tried before it's evolved and then eventually standardized.

369
00:31:31,680 --> 00:31:37,200
There's at least three different potential consensus incentive avenues.

370
00:31:37,200 --> 00:31:41,440
One is already in progress, which is a private initiative by Volksfinance.

371
00:31:41,440 --> 00:31:45,960
I do upload that massively and I'm a big fan that they are putting essentially their own

372
00:31:45,960 --> 00:31:50,960
algo from their own treasury into doing this.

373
00:31:50,960 --> 00:31:58,360
Another is, as we said, a theoretical consensus boost via Algorand Foundation governance.

374
00:31:58,360 --> 00:32:04,760
And the third, which is already being researched, is a protocol level incentive.

375
00:32:04,760 --> 00:32:09,960
And the research that we have right now in the form of actual like a pull request on

376
00:32:09,960 --> 00:32:21,000
GitHub is something that will divert a percentage of the fees of each block to the block proposer.

377
00:32:21,000 --> 00:32:26,360
The problem with the protocol level thing is that you can't really do slashing.

378
00:32:26,360 --> 00:32:32,480
And the benefit of doing it via Volks or via Algorand Foundation is that you can look at

379
00:32:32,480 --> 00:32:36,840
someone and say, you were meant to be online for three months, but for like one month out

380
00:32:36,840 --> 00:32:39,120
of that, you didn't vote once.

381
00:32:39,120 --> 00:32:45,000
So another thing to note about the Algorand consensus protocol is it is the voting part

382
00:32:45,000 --> 00:32:47,840
that makes it vulnerable to stalling.

383
00:32:47,840 --> 00:32:54,760
So during a single round of Algorand, there's going to be a block proposal and then two

384
00:32:54,760 --> 00:32:56,640
different votes.

385
00:32:56,640 --> 00:33:02,380
So if let's say that 50% of the network was not proposing blocks, that could actually

386
00:33:02,380 --> 00:33:06,480
cause some delays, but it would not stall the network because that round would time

387
00:33:06,480 --> 00:33:12,680
out and then another proposer would be selected and eventually a block would be proposed.

388
00:33:12,680 --> 00:33:19,760
If 50% of the network was not voting though, no block would actually pass the committees

389
00:33:19,760 --> 00:33:20,760
and be finalized.

390
00:33:20,760 --> 00:33:22,720
And so the network would be stalled.

391
00:33:22,720 --> 00:33:34,680
And so even from a conceptual point of view, filtering eligibility by proper voting is

392
00:33:34,680 --> 00:33:36,640
kind of the thing to do.

393
00:33:36,640 --> 00:33:41,800
However, there's a little bit of a problem there, which is that votes are not recorded

394
00:33:41,800 --> 00:33:43,160
on the blockchain.

395
00:33:43,160 --> 00:33:49,300
Each node records its own votes as it sees it and only up to the threshold that it needs

396
00:33:49,300 --> 00:33:52,080
to consider the block passed.

397
00:33:52,080 --> 00:33:57,960
And so a node in North America will have recorded different votes from a node in like South

398
00:33:57,960 --> 00:34:01,400
Africa, from a node in Japan and so on.

399
00:34:01,400 --> 00:34:07,920
However, the way I thought to work around this, at least in a, let's say statistically significant

400
00:34:07,920 --> 00:34:14,520
way would be to gather the votes from relay nodes.

401
00:34:14,520 --> 00:34:21,760
Relay nodes are also regular nodes aside from being the network backbone of Algorand.

402
00:34:21,760 --> 00:34:28,200
And part of their job is to also propagate blocks to nodes that are syncing up to the

403
00:34:28,200 --> 00:34:29,200
current state.

404
00:34:29,200 --> 00:34:36,080
And so if you sampled blocks from, let's say six nodes around the world, a few in the US,

405
00:34:36,080 --> 00:34:41,720
a few in Europe, a few in Asia, maybe one in Africa, you would actually end up with

406
00:34:41,720 --> 00:34:47,680
a pretty decent view of who was voting in each place at each time.

407
00:34:47,680 --> 00:34:55,420
And so that could get around the partial vote view on each node.

408
00:34:55,420 --> 00:35:01,320
As for the consensus-based incentives, one of the issues is that you can't do slashing.

409
00:35:01,320 --> 00:35:07,640
And so ideally you would like to only reward those who are participating properly.

410
00:35:07,640 --> 00:35:12,680
If you do it with transaction fees on a per block basis, then someone can be offline for

411
00:35:12,680 --> 00:35:15,840
half a year, thus actively harming the network.

412
00:35:15,840 --> 00:35:19,840
Because if enough nodes do that, then the network's going to stall.

413
00:35:19,840 --> 00:35:27,940
So I think that's very much a long-term vision, and currently there just are not enough transaction

414
00:35:27,940 --> 00:35:30,880
fees to make this a viable approach.

415
00:35:30,880 --> 00:35:37,800
So we're talking about a long-term plan, assuming that the holy grail of adoption and a lot

416
00:35:37,800 --> 00:35:41,160
more traffic on the network happens.

417
00:35:41,160 --> 00:35:52,640
As an idea of a fee generation over the course of 58 days, I reached out to the folks finance

418
00:35:52,640 --> 00:36:00,440
team to ask if they needed any help with figuring out who did their participation job well.

419
00:36:00,440 --> 00:36:07,440
And so I had some data already for a 58-day period between July 21st and September 17th,

420
00:36:07,440 --> 00:36:10,520
which is 58 days.

421
00:36:10,520 --> 00:36:15,280
And since I had that data already, I enriched it with transaction fees and posted on the

422
00:36:15,280 --> 00:36:19,880
pull request about the mining incentives for fees.

423
00:36:19,880 --> 00:36:26,760
And it turns out that the total fees of the protocol during that period was 59,343.

424
00:36:26,760 --> 00:36:33,080
So just as a comparison, my own node is a pretty good value for money dedicated server

425
00:36:33,080 --> 00:36:37,680
that I pay $27 a month for.

426
00:36:37,680 --> 00:36:38,780
That's fairly reasonable.

427
00:36:38,780 --> 00:36:41,880
You could go cheaper, but not by much.

428
00:36:41,880 --> 00:36:46,980
And I was also delegated a whole bunch of algo from various different people.

429
00:36:46,980 --> 00:36:53,320
And so the total stake was somewhere in the range of 800,000 to 900,000 algo.

430
00:36:53,320 --> 00:36:58,400
And assuming that a block proposer would get 100% of the fees, which is actually not the

431
00:36:58,400 --> 00:37:03,400
case, the fees that would correspond to me over that period would have been in the 20

432
00:37:03,400 --> 00:37:05,960
to 24 algo range.

433
00:37:05,960 --> 00:37:10,200
And the node cost over the same range was $54.

434
00:37:10,200 --> 00:37:13,480
So this is not a right now thing.

435
00:37:13,480 --> 00:37:20,760
This is let's plan for after short-term incentives thing, at least the way I see it because of

436
00:37:20,760 --> 00:37:23,440
the way the numbers work out.

437
00:37:23,440 --> 00:37:30,200
If I would have my say, then governance would continue rewarding more active participation

438
00:37:30,200 --> 00:37:31,200
in the network.

439
00:37:31,200 --> 00:37:35,600
And one of the most active participations you can have in the network is to run a node

440
00:37:35,600 --> 00:37:42,800
and secure it with your stake.

441
00:37:42,800 --> 00:37:48,960
In regards to, I guess, the aspects of the centralization, because I think you certainly

442
00:37:48,960 --> 00:37:55,400
did cover the topic of the consensus incentives in great detail.

443
00:37:55,400 --> 00:38:01,280
And yeah, I suppose we will have to see on the results of this, I guess, experimentation

444
00:38:01,280 --> 00:38:02,400
in the initial phase.

445
00:38:02,400 --> 00:38:07,000
But once again, certainly agree with you that having something like that on the consensus

446
00:38:07,000 --> 00:38:13,800
protocol level is an extremely challenging task, which is also limited by some of the

447
00:38:13,800 --> 00:38:18,440
features like lack of slashing and the others.

448
00:38:18,440 --> 00:38:23,600
So it's on the other hand, though, great to see that there are companies like Defolk's

449
00:38:23,600 --> 00:38:30,560
Finance standing strong in the ecosystem and they're doing some very good, I suppose, initiatives

450
00:38:30,560 --> 00:38:31,560
in regards to...

451
00:38:31,560 --> 00:38:34,960
For many different reasons.

452
00:38:34,960 --> 00:38:42,040
But speaking about the topic of the centralization, Algorand and Asium Foundation and Inc. basically

453
00:38:42,040 --> 00:38:49,240
continuing to evolve the network and the infrastructure and the whole shift towards peer-to-peer,

454
00:38:49,240 --> 00:38:55,840
which eventually should take care of completely removing the dependency on the relay nodes.

455
00:38:55,840 --> 00:39:00,740
And I think many people certainly do agree that this is definitely a step towards the

456
00:39:00,740 --> 00:39:01,740
right direction.

457
00:39:01,740 --> 00:39:10,200
But what do you think are the potential initial challenges that could be faced with incentivizing

458
00:39:10,200 --> 00:39:11,200
in this case?

459
00:39:11,200 --> 00:39:16,440
And aside from incentivization, I assume this can also touch a little bit on the engineering

460
00:39:16,440 --> 00:39:18,720
challenges in general.

461
00:39:18,720 --> 00:39:20,200
Right.

462
00:39:20,200 --> 00:39:26,120
So let me start by saying that as far as I'm aware, Algorand Inc. itself does not run any

463
00:39:26,120 --> 00:39:30,280
relays and I don't think the foundation does either.

464
00:39:30,280 --> 00:39:31,280
It's universities.

465
00:39:31,280 --> 00:39:38,280
Berkeley has one, MIT has one, a university in Italy that I don't recall has one, some

466
00:39:38,280 --> 00:39:41,600
partner companies also have relay nodes.

467
00:39:41,600 --> 00:39:46,080
And frankly, it's more of a conceptual thing.

468
00:39:46,080 --> 00:39:51,400
And given what we just spoke about with regards to Algorand Foundation's taking consensus

469
00:39:51,400 --> 00:40:00,400
currently, the relay centralization conversation is a little bit out of place.

470
00:40:00,400 --> 00:40:04,480
I mean, if the Algorand Foundation wanted to stall the network, they would not reach

471
00:40:04,480 --> 00:40:10,200
out to a hundred different companies and tell them to shut down their nodes.

472
00:40:10,200 --> 00:40:12,960
They would accidentally stop participating in consensus.

473
00:40:12,960 --> 00:40:15,080
Okay, that would be enough.

474
00:40:15,080 --> 00:40:21,700
So conceptually though, it's something to work around.

475
00:40:21,700 --> 00:40:26,480
Going peer to peer will first of all make relay nodes optional.

476
00:40:26,480 --> 00:40:31,800
I believe the plan is to still have them there as a fast path to the network.

477
00:40:31,800 --> 00:40:39,160
And it would also add some longevity to the network in case they can no longer be afforded

478
00:40:39,160 --> 00:40:44,200
because relays have really high requirements, especially network-wise.

479
00:40:44,200 --> 00:40:52,840
Both bandwidth and total throughput and bandwidth spend over each month.

480
00:40:52,840 --> 00:40:58,080
I'm not sure if by incentives you meant the consensus incentives that we spoke about,

481
00:40:58,080 --> 00:41:03,960
but I guess the way those would factor in is if you have decent enough consensus incentives

482
00:41:03,960 --> 00:41:12,840
and eventually the relay nodes go away, then that basically solves the problem of who is

483
00:41:12,840 --> 00:41:14,800
going to run the network.

484
00:41:14,800 --> 00:41:22,080
It's going to be people out of their data centers or homes without needing relay nodes.

485
00:41:22,080 --> 00:41:23,080
Yeah.

486
00:41:23,080 --> 00:41:30,960
Are you aware of any interesting, perhaps examples of other L1s at the moment who rely

487
00:41:30,960 --> 00:41:36,680
on peer to peer communication for running the networks in this case?

488
00:41:36,680 --> 00:41:39,080
Because I believe there's generally a trend though, right?

489
00:41:39,080 --> 00:41:44,520
Like whenever an L1 starts even looking at the governance models, it often does start

490
00:41:44,520 --> 00:41:46,920
as more or less centralized entity.

491
00:41:46,920 --> 00:41:51,720
And then as the community and the infrastructure is expanding, it starts spreading out and

492
00:41:51,720 --> 00:41:53,560
becoming more and more decentralized.

493
00:41:53,560 --> 00:41:56,280
But I wonder if there are...

494
00:41:56,280 --> 00:42:02,440
Not only on the technical layer of consensus, but in the stake as well, right?

495
00:42:02,440 --> 00:42:06,440
In proof of stake, usually everything is minted upfront.

496
00:42:06,440 --> 00:42:11,080
And so decentralizing it and getting it into the hands of many different people is part

497
00:42:11,080 --> 00:42:16,280
of the challenge, especially since you're usually going to need to have some funding

498
00:42:16,280 --> 00:42:17,280
as well.

499
00:42:17,280 --> 00:42:27,280
And so some of the people who will fund you upfront will be getting a lot more of it.

500
00:42:27,280 --> 00:42:32,440
But yeah, I assume I was just a bit curious on whether there are any interesting prominent

501
00:42:32,440 --> 00:42:37,160
examples of other L1s successfully implementing peer to peer in this case, because I would

502
00:42:37,160 --> 00:42:41,400
take as large sacrifice on finality maybe or the speed of transactions.

503
00:42:41,400 --> 00:42:46,600
I think Algorand was the exception with having an exclusive network layer of really fast

504
00:42:46,600 --> 00:42:55,080
relay nodes and that most L1s actually do have a peer to peer style functionality.

505
00:42:55,080 --> 00:42:59,880
Before we move on from the protocol level stuff, I wanted to share another thing that

506
00:42:59,880 --> 00:43:02,320
has me really, really excited.

507
00:43:02,320 --> 00:43:07,560
Just an anecdote from just yesterday, someone messaged me on Telegram asking me if Algorand

508
00:43:07,560 --> 00:43:09,800
is dead.

509
00:43:09,800 --> 00:43:12,120
And I don't think it's quite dead yet.

510
00:43:12,120 --> 00:43:17,880
We're in a really tough bear market and things have certainly slowed down a lot.

511
00:43:17,880 --> 00:43:24,160
And one of the things that makes me bullish is how much work the Inc. is putting into

512
00:43:24,160 --> 00:43:25,800
keeping up the innovation.

513
00:43:25,800 --> 00:43:31,760
And I believe that both the Inc. and the foundation are largely working on the right kind of things.

514
00:43:31,760 --> 00:43:38,160
One of the things that Algorand Inc. has cooking is dynamic round times.

515
00:43:38,160 --> 00:43:46,440
So that is going to drive round times in the average case scenario, I believe to about

516
00:43:46,440 --> 00:43:50,480
a second and in the best case scenario to under a second.

517
00:43:50,480 --> 00:43:56,440
So if we are looking forward to maybe six or nine months from now, we're looking at

518
00:43:56,440 --> 00:43:59,680
a network that has peer to peer paths.

519
00:43:59,680 --> 00:44:07,480
It has fast relays as a shortcut or as an optional way to get to other consensus participants

520
00:44:07,480 --> 00:44:16,120
sooner and the round time is not capped to three seconds or 3.34, whatever we are now.

521
00:44:16,120 --> 00:44:23,200
And so looking at the two organizations involved that keep working on the right things, Algorand

522
00:44:23,200 --> 00:44:29,040
Foundation also doing a lot in developer experience and Algorand and AlgoKit and Tealscript and

523
00:44:29,040 --> 00:44:33,600
all of that is one of the things that keeps me bullish.

524
00:44:33,600 --> 00:44:38,320
They don't seem to have thrown in the towel and I don't see a reason for, especially someone

525
00:44:38,320 --> 00:44:42,200
in my shoes to throw the towel in either.

526
00:44:42,200 --> 00:44:46,440
Yeah, as for box storage, I think box storage...

527
00:44:46,440 --> 00:44:55,680
If I may just chime in and add a little bit, I think just to maybe highlight some of the

528
00:44:55,680 --> 00:45:01,280
recent things and the things to come in regards to the improvements to the AlgoKit, which

529
00:45:01,280 --> 00:45:06,560
for some listeners who may not be aware of what AlgoKit is, it's a completely open source

530
00:45:06,560 --> 00:45:08,360
set of developer tooling.

531
00:45:08,360 --> 00:45:14,120
If you come from different backgrounds, like say iOS development, you can think of AlgoKit

532
00:45:14,120 --> 00:45:17,720
as a fast lane for everything to do with Algorand.

533
00:45:17,720 --> 00:45:23,320
There's a lot of things that are being expanded such as you can run a single command these

534
00:45:23,320 --> 00:45:24,320
days.

535
00:45:24,320 --> 00:45:29,040
If you're familiar with Create React app, you can create a full stack application, fully

536
00:45:29,040 --> 00:45:31,640
customizable, almost production grade.

537
00:45:31,640 --> 00:45:37,720
You have end-to-end tests, you have unit tests, you have workflows and everything integrated

538
00:45:37,720 --> 00:45:42,080
for you to basically start building an application.

539
00:45:42,080 --> 00:45:44,880
And showed out to, of course, a lot of people at the DevRel.

540
00:45:44,880 --> 00:45:50,760
I think it's easy to overlook the hard work that is happening despite the harsh conditions

541
00:45:50,760 --> 00:45:51,760
of the bear market.

542
00:45:51,760 --> 00:45:54,800
Yeah, like being an observer of the things happening internally.

543
00:45:54,800 --> 00:45:55,800
That's exactly right.

544
00:45:55,800 --> 00:45:56,800
Yeah.

545
00:45:56,800 --> 00:46:02,120
It's basically a scaffolding tool to get you set up with some structures ready to go and

546
00:46:02,120 --> 00:46:06,480
a big bag of utilities that are really nice to have.

547
00:46:06,480 --> 00:46:12,160
Some of the stuff will already have been created in like home labs and company labs already,

548
00:46:12,160 --> 00:46:14,820
but having one place to have them all.

549
00:46:14,820 --> 00:46:18,860
It has really cool things like being able to generate JavaScript or TypeScript clients

550
00:46:18,860 --> 00:46:23,360
for your smart contract already so that you don't have to spend the time trying to figure

551
00:46:23,360 --> 00:46:30,120
out what make application from suggested parameters field names are.

552
00:46:30,120 --> 00:46:37,040
And yeah, it's one of the game-changing utilities that the foundation has put out.

553
00:46:37,040 --> 00:46:43,080
And TealScript is also not to be overlooked, which is a TypeScript like language that compiles

554
00:46:43,080 --> 00:46:44,880
to Teal.

555
00:46:44,880 --> 00:46:51,080
And then also PyTeal will evolve to be a lot more Python, native Python life.

556
00:46:51,080 --> 00:46:52,080
Exactly.

557
00:46:52,080 --> 00:46:57,280
So a lot of people are complaining about the foundation, but honestly, just the developer

558
00:46:57,280 --> 00:47:01,820
relations, the developer experience side of things that they are working on, I'd like

559
00:47:01,820 --> 00:47:04,920
to hear how they do better than that, right?

560
00:47:04,920 --> 00:47:10,340
Because making developers' lives easier is a key part to getting to adoption, to getting

561
00:47:10,340 --> 00:47:13,440
to people building on Algorand.

562
00:47:13,440 --> 00:47:19,200
Exactly, and I can't wait to see what people's reactions are going to be closer to the beginning

563
00:47:19,200 --> 00:47:23,000
of the next year, once a lot of the things in the roadmap are out.

564
00:47:23,000 --> 00:47:27,520
And I can assure that there's going to be a lot more additions to Algorand in general,

565
00:47:27,520 --> 00:47:29,020
as well as the transpiler.

566
00:47:29,020 --> 00:47:33,200
Having a bit more native support to Python is a huge game changer.

567
00:47:33,200 --> 00:47:38,800
And just looking at the way smart contracts have been built for the past three years,

568
00:47:38,800 --> 00:47:42,160
it's potentially going to be the easiest way so far.

569
00:47:42,160 --> 00:47:47,620
And TealScript is already a glimpse into that, if you are more on the web script side of

570
00:47:47,620 --> 00:47:48,620
things.

571
00:47:48,620 --> 00:47:53,520
And yeah, shout out to Joe Polny from DevRel for doing an amazing job on this tech.

572
00:47:53,520 --> 00:47:54,520
Yeah, indeed.

573
00:47:54,520 --> 00:47:55,520
Box storage then?

574
00:47:55,520 --> 00:47:56,520
Box storage.

575
00:47:56,520 --> 00:48:01,280
All right, box storage feels like old news by now.

576
00:48:01,280 --> 00:48:10,760
But when it came out, it basically lifted the size restrictions for Algorand smart contracts.

577
00:48:10,760 --> 00:48:16,720
One of my first dApps was either just before or just after box storage was released.

578
00:48:16,720 --> 00:48:23,880
And I was not using box storage and I had to have a second contract just to abuse its

579
00:48:23,880 --> 00:48:33,880
storage functionality because I needed just over 64 things, which used to be the limit

580
00:48:33,880 --> 00:48:36,320
for the global storage.

581
00:48:36,320 --> 00:48:41,280
So with boxes, you can have, it's a key value store.

582
00:48:41,280 --> 00:48:46,800
The length of the key and the value combined can be up to 32 kilobytes.

583
00:48:46,800 --> 00:48:55,960
And using one raises the minimum balance requirements of your contract's address by a little bit.

584
00:48:55,960 --> 00:49:00,680
It was something that was needed to have.

585
00:49:00,680 --> 00:49:08,640
And it's really exciting to be able to store almost arbitrary length using multiple boxes

586
00:49:08,640 --> 00:49:11,320
data in smart contracts.

587
00:49:11,320 --> 00:49:18,960
Without box storage, one of my recent projects I did with the EXA NFT marketplace would not

588
00:49:18,960 --> 00:49:20,900
really have been possible.

589
00:49:20,900 --> 00:49:27,440
They wanted to, they run a rewards program for using their platform as they are one of

590
00:49:27,440 --> 00:49:31,120
the most recent additions to the NFT marketplace space.

591
00:49:31,120 --> 00:49:36,160
I think they launched in November of 2022.

592
00:49:36,160 --> 00:49:41,480
So they run a rewards program where using the platform would earn you loot boxes, which

593
00:49:41,480 --> 00:49:44,880
was a multi-ment NFT.

594
00:49:44,880 --> 00:49:51,560
And they wanted an on-chain shuffle of prices based on the NFTs that you held.

595
00:49:51,560 --> 00:49:56,340
And so you would exchange one for one of any number of prices.

596
00:49:56,340 --> 00:49:59,560
Any number turned out to be 6,000 or so.

597
00:49:59,560 --> 00:50:06,440
I will make sure to include the link to the post by the way, which is a great breakdown

598
00:50:06,440 --> 00:50:10,120
of what you did there and in regards to VRFs as well.

599
00:50:10,120 --> 00:50:11,120
Right.

600
00:50:11,120 --> 00:50:12,120
Yeah, thanks.

601
00:50:12,120 --> 00:50:14,320
It was fun writing it up.

602
00:50:14,320 --> 00:50:16,480
I'm fairly proud of that effort.

603
00:50:16,480 --> 00:50:23,680
So yeah, the long and short of it is that we needed to store 4,000 asset IDs somewhere.

604
00:50:23,680 --> 00:50:28,020
That was entirely out of the question without having boxes.

605
00:50:28,020 --> 00:50:35,480
And so for simplicity sake, I ended up using a single box and I could also get away with

606
00:50:35,480 --> 00:50:43,320
storing only half of the asset ID, by which I mean asset IDs have a maximum 64-bit integer.

607
00:50:43,320 --> 00:50:49,240
But right now we are at asset ID 1.2 or 1.3 billion, something like that, which fits very

608
00:50:49,240 --> 00:50:51,520
nicely into a UINT32.

609
00:50:51,520 --> 00:50:58,260
So with a few optimizations, I could have a single box and store all of the asset IDs.

610
00:50:58,260 --> 00:51:04,120
And then yeah, basically treated that as a list ordered by a rarity, since there were

611
00:51:04,120 --> 00:51:10,480
some mechanics where some rare loot boxes were guaranteed like a top 25 or top 6.25%

612
00:51:10,480 --> 00:51:12,520
of the price.

613
00:51:12,520 --> 00:51:22,800
And whenever a price was allocated, I would have to rewrite the box to be the same, but

614
00:51:22,800 --> 00:51:25,800
with a drawn price missing.

615
00:51:25,800 --> 00:51:31,720
One of the limitations in the AVM is that the maximum byte string that you can have

616
00:51:31,720 --> 00:51:38,680
is 4 kilobytes long, which I discovered fairly late as I was testing with a full box of about

617
00:51:38,680 --> 00:51:42,200
like 28 kilobytes.

618
00:51:42,200 --> 00:51:47,560
And when a rare price was drawn at the beginning of the list, I would try to rewrite the box

619
00:51:47,560 --> 00:51:50,000
and it would overflow the 4 kilobytes size.

620
00:51:50,000 --> 00:51:54,000
So I had to basically do the same thing, but in 4 kilobytes chunks.

621
00:51:54,000 --> 00:51:58,040
So copy 4 kilobytes, all right, copy the next 4 kilobytes and so on.

622
00:51:58,040 --> 00:52:04,800
And I think that my subtle complaining in the article on the site about VRF and the

623
00:52:04,800 --> 00:52:10,320
challenges of working with box thirds contributed to two new opcodes coming to the AVM, which

624
00:52:10,320 --> 00:52:15,960
is a box splice and box resize, which does what it sounds like.

625
00:52:15,960 --> 00:52:23,080
So the box splice would be to remove a chunk out of a box atomically with a single op and

626
00:52:23,080 --> 00:52:28,120
then box resize is to resize an existing box, which we also didn't have.

627
00:52:28,120 --> 00:52:31,920
So I'll take a very little tiny bit of credit for that.

628
00:52:31,920 --> 00:52:39,400
But my major point here is that it's great to see Algorand Inc. who does not have the

629
00:52:39,400 --> 00:52:43,480
largest reputation of being loud and super involved in the space.

630
00:52:43,480 --> 00:52:48,640
They are, however, listening and addressing because for them it's fairly low hanging fruit

631
00:52:48,640 --> 00:52:50,360
to add that, right?

632
00:52:50,360 --> 00:52:55,120
If it's not junk, if it's not going to keep up, just take up space for no reason and a

633
00:52:55,120 --> 00:52:58,920
reasonable use case, then it's not going to cost us too much to add it.

634
00:52:58,920 --> 00:53:01,520
So let's add it and make your life easier.

635
00:53:01,520 --> 00:53:08,720
I must say I discovered this 4 kilobyte limitation quite late as well.

636
00:53:08,720 --> 00:53:13,520
Some of the projects I've been working on, but it's certainly great to see the things

637
00:53:13,520 --> 00:53:14,520
like splice.

638
00:53:14,520 --> 00:53:17,040
I think that's going to be very useful in this case.

639
00:53:17,040 --> 00:53:22,840
In terms of maybe things that it also enables, if I may add, I think one other interesting

640
00:53:22,840 --> 00:53:27,760
aspect to it is just it adds a little bit more flexibility in terms of readability of

641
00:53:27,760 --> 00:53:33,560
the contracts in general, because you don't really need to touch up on the global state,

642
00:53:33,560 --> 00:53:34,560
right?

643
00:53:34,560 --> 00:53:39,880
It's something that potentially you want to store in a global state and it's certainly

644
00:53:39,880 --> 00:53:45,400
not feasible to do so if you want to have an updateable contract because a change in

645
00:53:45,400 --> 00:53:48,240
a global state is not considered as an update.

646
00:53:48,240 --> 00:53:51,840
It's actually a breaking change in this case, right?

647
00:53:51,840 --> 00:53:52,840
You can't really...

648
00:53:52,840 --> 00:53:53,840
You can't really...

649
00:53:53,840 --> 00:53:57,400
Like the second you start dealing with the global state in this case, the ability becomes

650
00:53:57,400 --> 00:53:58,400
a bit tricky.

651
00:53:58,400 --> 00:54:04,160
But if you can squeeze in a lot of information into the boxes, for example, that's what I

652
00:54:04,160 --> 00:54:10,280
believe the folks at NFD are doing with the way they handle the updateability of the contracts.

653
00:54:10,280 --> 00:54:13,520
Yeah, box storage is particularly useful in this case.

654
00:54:13,520 --> 00:54:14,520
But what do you...

655
00:54:14,520 --> 00:54:22,200
That said, it's not quite throughout global storage yet because the limitations are fairly

656
00:54:22,200 --> 00:54:23,360
significant.

657
00:54:23,360 --> 00:54:28,000
One of them is that they are private to each contract within on-chain.

658
00:54:28,000 --> 00:54:31,560
So I can't read your applications box.

659
00:54:31,560 --> 00:54:36,360
With global storage, you can read another application's global storage quite easily.

660
00:54:36,360 --> 00:54:42,320
You need to have it declared as a foreign app that you will look at or touch.

661
00:54:42,320 --> 00:54:45,440
And then you can just read their global storage.

662
00:54:45,440 --> 00:54:51,400
With boxes, the only way to access another application's box is if they expose an ABI

663
00:54:51,400 --> 00:54:54,800
method to give you that box's data.

664
00:54:54,800 --> 00:55:03,080
And then the second thing is that it's not quite integrated in indexers.

665
00:55:03,080 --> 00:55:07,280
And so it's not part of the block delta as you would get it from an indexer.

666
00:55:07,280 --> 00:55:12,800
If you want to track a box change during a transaction, I believe you can get that out

667
00:55:12,800 --> 00:55:19,960
of the transaction, out of the ledger delta APIs, but I have not actually confirmed that.

668
00:55:19,960 --> 00:55:22,440
So part of my medium term plans is actually to...

669
00:55:22,440 --> 00:55:26,400
I'm writing an explorer that's going to be on Algorand.observer.

670
00:55:26,400 --> 00:55:32,400
I'm not sure if that ever will be completed, especially the way I have it, but the ledger

671
00:55:32,400 --> 00:55:37,960
delta APIs is something that could be utilized in a good blockchain explorer as well.

672
00:55:37,960 --> 00:55:44,000
And to my knowledge so far, it hasn't been.

673
00:55:44,000 --> 00:55:50,920
If I were to mention on the things that potentially the only, I guess, tricky part around dealing

674
00:55:50,920 --> 00:55:55,280
with boxes is MBR, calculating the minimum balance requirement.

675
00:55:55,280 --> 00:56:00,960
I feel like that aspect could potentially get a little bit easier, just maybe something

676
00:56:00,960 --> 00:56:06,240
that is baked in on the level of the core SDKs or something like that, that allows you

677
00:56:06,240 --> 00:56:11,960
to quickly, dynamically calculate the fee that you need to pay to interact with the

678
00:56:11,960 --> 00:56:14,800
contract.

679
00:56:14,800 --> 00:56:19,600
It obviously can be covered by developer if you're providing an ABI interface to someone

680
00:56:19,600 --> 00:56:20,680
to consume.

681
00:56:20,680 --> 00:56:25,040
But for the developer himself, building tests and all of that, that's potentially when it

682
00:56:25,040 --> 00:56:29,280
just gets a little trickier to dynamically control it.

683
00:56:29,280 --> 00:56:34,640
Especially if you're dealing with dynamic bytes or if you're storing different mappings

684
00:56:34,640 --> 00:56:35,640
in there.

685
00:56:35,640 --> 00:56:42,800
I hear that, but I think a more challenging scenario is when you're charging users for

686
00:56:42,800 --> 00:56:48,600
the box stores that they are using, because then you have another value to keep.

687
00:56:48,600 --> 00:56:51,200
You've paid up to that much.

688
00:56:51,200 --> 00:56:54,880
If you want to expand, you need to pay that much more.

689
00:56:54,880 --> 00:57:01,000
If you're just calculating it off-chain, the formula is, I think, 2,500 plus 400 times

690
00:57:01,000 --> 00:57:05,080
the number of bytes in microalgo.

691
00:57:05,080 --> 00:57:06,080
That's fine.

692
00:57:06,080 --> 00:57:14,680
But in having to keep track of that on-chain is where it might be a little bit more cumbersome.

693
00:57:14,680 --> 00:57:19,840
You did mention that you're working on a set of very interesting projects that also touch

694
00:57:19,840 --> 00:57:23,720
on the box storage.

695
00:57:23,720 --> 00:57:29,600
Unless you want to jump into base 32 already, any chance you can also expand a little bit

696
00:57:29,600 --> 00:57:35,280
on the tool that you've mentioned that does the collaborative doc editing?

697
00:57:35,280 --> 00:57:38,840
Does this, if I get it correctly, utilize box storage?

698
00:57:38,840 --> 00:57:44,400
If yes, how do you achieve this particular capability?

699
00:57:44,400 --> 00:57:53,240
One thing that I started to build, it's 99% ready to ship, and I parked is called base

700
00:57:53,240 --> 00:57:58,880
32 fund.

701
00:57:58,880 --> 00:58:04,960
The idea there is to have a crowdfunding application where you can set a minimum and a maximum

702
00:58:04,960 --> 00:58:11,560
of the amount that you're raising, but also the title and the description of your fundraiser

703
00:58:11,560 --> 00:58:13,040
would be stored on-chain.

704
00:58:13,040 --> 00:58:23,120
And so it would be entirely self-contained, and you wouldn't have to go to IPFS to fetch

705
00:58:23,120 --> 00:58:28,040
a blob of text or markdown to show to the user.

706
00:58:28,040 --> 00:58:33,240
And then the reason that this is parked is, well, two challenges there.

707
00:58:33,240 --> 00:58:44,120
One is figuring out how to censor spam and scams and things that are basically a danger

708
00:58:44,120 --> 00:58:46,400
to the project and the community.

709
00:58:46,400 --> 00:58:49,440
And that's a little bit of a hard problem to do.

710
00:58:49,440 --> 00:58:55,760
So I wouldn't be able to delete your fundraiser, but if you are raising money for terrorism

711
00:58:55,760 --> 00:59:00,920
or whatever, then it's probably not something that I want exposed on the front end.

712
00:59:00,920 --> 00:59:04,760
And so, I mean, that's actually the minor point.

713
00:59:04,760 --> 00:59:13,480
And the major point is that I want to build a set of tools around the base 32 name or

714
00:59:13,480 --> 00:59:14,880
brand.

715
00:59:14,880 --> 00:59:20,720
And one of those is going to be called base 32 space.

716
00:59:20,720 --> 00:59:27,420
And the two aspects there are going to be one, I want to create a file system-like interface

717
00:59:27,420 --> 00:59:31,040
for smart contracts to store files on Algorand.

718
00:59:31,040 --> 00:59:37,200
Yes, I do know IPFS is a thing and it's usually a much cheaper thing.

719
00:59:37,200 --> 00:59:41,640
Algorand box storage is relatively expensive compared to competition.

720
00:59:41,640 --> 00:59:49,360
However, if you have a good enough reason to store things on Algorand, or if you want

721
00:59:49,360 --> 00:59:56,200
to actually operate on the data from a smart contract, then in the first case, you have

722
00:59:56,200 --> 00:59:58,280
it completely self-sustained.

723
00:59:58,280 --> 01:00:03,880
So you don't need to also pay an IPFS pinning service to keep your thing online.

724
01:00:03,880 --> 01:00:10,560
And in the second, you can't really interact with IPFS data from the Algorand blockchain.

725
01:00:10,560 --> 01:00:17,680
And so being able to have a file in a smart contract would enable things like that file

726
01:00:17,680 --> 01:00:19,720
being a template.

727
01:00:19,720 --> 01:00:25,400
And then maybe having some VRF output or maybe some algorithm that derives some content to

728
01:00:25,400 --> 01:00:32,520
the file from the user's address to randomize some colors in an SVG or something.

729
01:00:32,520 --> 01:00:40,600
And so I stopped base32 fund because it's going to be based eventually on base32 space.

730
01:00:40,600 --> 01:00:45,640
And I need to figure out what the best way for that is to look like.

731
01:00:45,640 --> 01:00:52,480
And then probably an arc would be in good measure there as well.

732
01:00:52,480 --> 01:00:59,440
And the middle part between the file system thing and the fundraiser is actually something

733
01:00:59,440 --> 01:01:06,040
that base32 fund already implements, which is to store Markdown and then render it on

734
01:01:06,040 --> 01:01:09,400
the client.

735
01:01:09,400 --> 01:01:18,320
The first concern is that I'm not 100% confident that it would be secure from, let's say, code

736
01:01:18,320 --> 01:01:23,360
injection because I haven't actually written the Markdown renderer myself.

737
01:01:23,360 --> 01:01:27,400
I'll figure that out when we get to actually launching.

738
01:01:27,400 --> 01:01:33,920
But something that might be interesting is to have the equivalent of Google Docs on chain.

739
01:01:33,920 --> 01:01:40,240
So if let's say base32 space file system is already launched, then we have a generic container

740
01:01:40,240 --> 01:01:43,120
to store files.

741
01:01:43,120 --> 01:01:47,760
By the way, the idea there is to also be able to have them compressed so you would pay a

742
01:01:47,760 --> 01:01:48,920
lot less.

743
01:01:48,920 --> 01:01:55,080
So you'd have a field to say that this is a gzip or deflate or LZ4 or whatever.

744
01:01:55,080 --> 01:02:00,240
And then it would be up to the client to apply the right decompression to get to the actual

745
01:02:00,240 --> 01:02:01,820
data.

746
01:02:01,820 --> 01:02:09,840
And so for documents, the reasons that one might want to have it on chain is mostly to

747
01:02:09,840 --> 01:02:14,240
be able to interact with it either as a user or as a smart contract.

748
01:02:14,240 --> 01:02:20,960
So as a user, I might want to, as D13, I might want to publish my manifesto about Coop and

749
01:02:20,960 --> 01:02:27,640
then people might want to comment on it or upvote it or downvote it and introduce social

750
01:02:27,640 --> 01:02:31,760
elements into the document itself.

751
01:02:31,760 --> 01:02:36,900
And then a second generation idea on that would be to have the equivalent of pull requests

752
01:02:36,900 --> 01:02:44,240
or merge requests where someone proposes a change on chain again via a Delta document

753
01:02:44,240 --> 01:02:48,160
that I can then look at and see that, okay, he's just fixing a typo.

754
01:02:48,160 --> 01:02:49,160
That's great.

755
01:02:49,160 --> 01:02:53,200
And I can incorporate that into my own.

756
01:02:53,200 --> 01:03:00,360
And so yeah, I kind of built base32 fund as backwards because the ideal way would be to

757
01:03:00,360 --> 01:03:06,280
get a file system like thing together and then work on the document storage and especially

758
01:03:06,280 --> 01:03:11,200
the client side rendering properly to make sure that the no baddies can end up in HTML

759
01:03:11,200 --> 01:03:16,520
and then base32 fund, which actually utilizes the showing a document.

760
01:03:16,520 --> 01:03:22,240
I think I'm starting to get it in a much more context now and it's the more you think about

761
01:03:22,240 --> 01:03:24,520
it, the more exciting it starts to sound.

762
01:03:24,520 --> 01:03:28,200
Are you familiar with Soled by Tim Berners-Lee?

763
01:03:28,200 --> 01:03:31,720
No, I don't think I've seen that.

764
01:03:31,720 --> 01:03:42,600
It's something that touches on link data space in general, but I think this is potentially

765
01:03:42,600 --> 01:03:47,840
a more practical way to solve the problem because the thing with Soled is that they

766
01:03:47,840 --> 01:03:55,920
basically are building this set of new protocols, expanding on the open web standards to have

767
01:03:55,920 --> 01:04:05,560
a way to deal with access control in a way where you represent the data as semantic data

768
01:04:05,560 --> 01:04:06,560
basically.

769
01:04:06,560 --> 01:04:11,600
So you could say like, okay, this is a set of pictures of files that you as an app can

770
01:04:11,600 --> 01:04:13,160
access or can't access.

771
01:04:13,160 --> 01:04:17,860
But I feel like with what you're doing here with the file system, this can also potentially

772
01:04:17,860 --> 01:04:25,240
be expanded into something that also provides a more robust access control to files.

773
01:04:25,240 --> 01:04:31,040
If you're primarily aiming this to be like, I assume the hardest challenge you have is

774
01:04:31,040 --> 01:04:34,200
getting the file in there, getting it on chain.

775
01:04:34,200 --> 01:04:40,000
The second you have it stored, accessing this particular information or loading this back

776
01:04:40,000 --> 01:04:46,200
is could potentially be a little bit more trivial, but this can also be expanded to

777
01:04:46,200 --> 01:04:48,080
have access control rights around it.

778
01:04:48,080 --> 01:04:54,640
You can imagine like maybe storing files and having some sort of social network thing that

779
01:04:54,640 --> 01:05:00,120
is reading information through smart contracts and then they can use your file system and

780
01:05:00,120 --> 01:05:04,480
know which particular boxes they can access or can't access.

781
01:05:04,480 --> 01:05:09,480
But I'm just speculating, but once you started describing this in detail, this really reminded

782
01:05:09,480 --> 01:05:12,040
me of Soled a lot.

783
01:05:12,040 --> 01:05:13,320
Interesting.

784
01:05:13,320 --> 01:05:17,700
So anything that goes into a box has to be considered public domain, right?

785
01:05:17,700 --> 01:05:22,920
But then whether something would be fetchable from other smart contracts could be part of

786
01:05:22,920 --> 01:05:24,520
the access control.

787
01:05:24,520 --> 01:05:31,280
Another thing to be considered is if something is mutable at all, I think there's a use case

788
01:05:31,280 --> 01:05:34,400
for something that cannot be updated even by the owner.

789
01:05:34,400 --> 01:05:39,280
And then accepting the social elements that we spoke about, about upvotes, downvotes,

790
01:05:39,280 --> 01:05:43,960
comments, pull requests and so on is probably going to be another aspect.

791
01:05:43,960 --> 01:05:49,320
But as for getting the data on chain, it's actually not that big of a deal.

792
01:05:49,320 --> 01:05:54,160
You have a limitation of two kilobytes in application arguments, but you just do it

793
01:05:54,160 --> 01:05:56,440
in two kilobyte chunks and it's fine.

794
01:05:56,440 --> 01:06:01,560
It's not particularly...

795
01:06:01,560 --> 01:06:11,000
And what about the cases when you want to read a large chunk of data on chain considering

796
01:06:11,000 --> 01:06:15,240
the limitation, but I assume once again you just deal with chunks in this case.

797
01:06:15,240 --> 01:06:16,240
Right.

798
01:06:16,240 --> 01:06:17,240
Yes.

799
01:06:17,240 --> 01:06:18,560
That would be a little bit trickier.

800
01:06:18,560 --> 01:06:23,200
I assume four kilobytes is going to be the upper limit to that because of the byte string

801
01:06:23,200 --> 01:06:25,120
that you can store on the receiver side.

802
01:06:25,120 --> 01:06:30,800
I'm actually not sure if contract to contract, some methods have a limit on how large they

803
01:06:30,800 --> 01:06:31,800
are.

804
01:06:31,800 --> 01:06:37,200
It could be two kilobytes or four, but I haven't looked into that much.

805
01:06:37,200 --> 01:06:39,400
And what do you think is the...

806
01:06:39,400 --> 01:06:45,560
What's going to be the best way for the community to provide feedback or test out the platform

807
01:06:45,560 --> 01:06:51,760
once you think you have some initial maybe beta version of the space, the base 32 spaces

808
01:06:51,760 --> 01:06:52,760
first?

809
01:06:52,760 --> 01:06:53,760
Right.

810
01:06:53,760 --> 01:06:59,200
I think I either need to do a prototype first of how it's going to work, which is actually

811
01:06:59,200 --> 01:07:01,080
in progress already.

812
01:07:01,080 --> 01:07:06,880
And then the second part would be to get feedback informally and then publish an ARC because

813
01:07:06,880 --> 01:07:09,520
it would be really cool.

814
01:07:09,520 --> 01:07:13,560
It's not just, okay, you put a file on a contract.

815
01:07:13,560 --> 01:07:19,440
What's more exciting to me is something that fulfills the file interface, but is also a

816
01:07:19,440 --> 01:07:23,720
fundraiser, is also a love letter, is also a something else.

817
01:07:23,720 --> 01:07:29,400
So it has a standardized way of both clients and other smart contracts to modify or check

818
01:07:29,400 --> 01:07:35,080
out the state or whatever, but it is also like a fundraiser or something.

819
01:07:35,080 --> 01:07:36,760
So yeah, go ahead.

820
01:07:36,760 --> 01:07:43,060
Would that be something you as a user deploy or would that be more of a factory contract

821
01:07:43,060 --> 01:07:48,000
of sorts you just interact with and that takes care of mincing the contract that will act

822
01:07:48,000 --> 01:07:49,000
as a storage?

823
01:07:49,000 --> 01:07:54,120
Probably a factory contract that spawns a subcontract.

824
01:07:54,120 --> 01:08:00,920
This could allow, so a problem with the user deploying contracts is how to actually index

825
01:08:00,920 --> 01:08:04,240
all of them.

826
01:08:04,240 --> 01:08:10,720
And also if you need to interact with a smart contract that has a box storage or needs to

827
01:08:10,720 --> 01:08:17,040
opt into, that needs any sort of minimum balance, you have to do it in two steps normally, right?

828
01:08:17,040 --> 01:08:21,840
You have to first create it in order to see what the tap ID is, which is going to define

829
01:08:21,840 --> 01:08:27,320
what the escrow address is and then fund the escrow address and then you can create the

830
01:08:27,320 --> 01:08:30,640
box and then you can opt it into an ASA.

831
01:08:30,640 --> 01:08:37,280
However, base32fund allows you to create a fundraiser, which does use box storage in

832
01:08:37,280 --> 01:08:39,080
one go.

833
01:08:39,080 --> 01:08:45,320
And the way I'm doing this is I have a like deployer pattern where the main contract on

834
01:08:45,320 --> 01:08:51,600
chain has already created templates of smart contracts that are just empty, but they are

835
01:08:51,600 --> 01:08:55,560
known and it has a box of let's say a hundred of them.

836
01:08:55,560 --> 01:08:59,980
And when you want to create a fundraiser, you pick one of them at random and then you

837
01:08:59,980 --> 01:09:05,360
transact as if it's going to be available in three or five seconds since you last read

838
01:09:05,360 --> 01:09:09,600
it or maybe 30 seconds since we're going to include signing.

839
01:09:09,600 --> 01:09:16,640
And assuming that no one else sniped that up in the meantime, then you can basically

840
01:09:16,640 --> 01:09:18,640
just start using it immediately.

841
01:09:18,640 --> 01:09:21,440
The main contract is going to reassign it to you.

842
01:09:21,440 --> 01:09:27,360
So the permissionless, it can also be permissionless from the platform point of view after you actually

843
01:09:27,360 --> 01:09:28,560
create it.

844
01:09:28,560 --> 01:09:29,560
Yeah.

845
01:09:29,560 --> 01:09:33,860
And you don't have to wait for the contract to be created because it will be pre-created

846
01:09:33,860 --> 01:09:35,080
for you.

847
01:09:35,080 --> 01:09:41,040
And also for this to be sustainable, the contract will also replace the application that was

848
01:09:41,040 --> 01:09:45,200
just taken with a new one on the spot.

849
01:09:45,200 --> 01:09:48,480
And so you won't run out after a hundred have been spawned.

850
01:09:48,480 --> 01:09:50,920
That's very interesting.

851
01:09:50,920 --> 01:09:55,920
What about just general end goal that you have with this project?

852
01:09:55,920 --> 01:10:01,560
Would you aim to have this as a protocol or you'd want to have some somewhat of a sustainable

853
01:10:01,560 --> 01:10:06,320
business model for it, not to say that protocols don't have sustainable business models, but

854
01:10:06,320 --> 01:10:14,600
usually once you open source something, it becomes more of a ideological sort of goal

855
01:10:14,600 --> 01:10:19,760
to fulfill rather than something to monetize and generate revenue from.

856
01:10:19,760 --> 01:10:27,040
So I haven't thought in very much depth about this, but my current intention is for, you

857
01:10:27,040 --> 01:10:31,520
would be able to create a file if you wanted in the same format, but it would probably

858
01:10:31,520 --> 01:10:35,760
not be available through base32 space domain.

859
01:10:35,760 --> 01:10:42,920
So part of this is going to be a front end interface that will serve either a page with

860
01:10:42,920 --> 01:10:45,920
the description of the file and be able to interact with it.

861
01:10:45,920 --> 01:10:50,680
But you'd also get like a raw URL to get just the file itself.

862
01:10:50,680 --> 01:10:55,620
So if you just created something that conforms to the interface, but it was not done through

863
01:10:55,620 --> 01:11:00,000
the base32 space main contract, then it would not be indexed.

864
01:11:00,000 --> 01:11:03,200
That wouldn't even be a malicious thing, a profit driven thing.

865
01:11:03,200 --> 01:11:08,520
It would just be the way that it works because the active application IDs will either be

866
01:11:08,520 --> 01:11:14,480
stored in a box on the main contract as well, just to be able to get them easily, or they'd

867
01:11:14,480 --> 01:11:19,680
be discovered by looking at an indexer and seeing who interacted with the main contract

868
01:11:19,680 --> 01:11:24,280
in order to figure out who's created like files or file buckets.

869
01:11:24,280 --> 01:11:27,040
I see.

870
01:11:27,040 --> 01:11:28,840
I see.

871
01:11:28,840 --> 01:11:34,480
And I know to be a little bit more cautious of time, but usually find the questions around

872
01:11:34,480 --> 01:11:40,480
particular implementation challenges or discussions on individual platforms the most engaging.

873
01:11:40,480 --> 01:11:46,480
But anything in particular as a closing note, perhaps for the base32 project that you can

874
01:11:46,480 --> 01:11:51,240
mention in regards to the main challenges you face so far, I assume this would be the

875
01:11:51,240 --> 01:11:54,400
part about what you've mentioned in the beginning, right?

876
01:11:54,400 --> 01:11:58,400
Like building the space before dealing with the fund part.

877
01:11:58,400 --> 01:12:04,040
The aspect is like before dealing with the funding part, you want to have a more general

878
01:12:04,040 --> 01:12:09,280
sort of banning mechanisms perhaps or ways to detect malicious actors?

879
01:12:09,280 --> 01:12:11,600
Yeah, moderation.

880
01:12:11,600 --> 01:12:12,600
It's a conceptual problem.

881
01:12:12,600 --> 01:12:17,800
It is a hard problem to solve in a permissionless or decentralized system.

882
01:12:17,800 --> 01:12:21,360
And the main problem there would be moderation.

883
01:12:21,360 --> 01:12:24,280
So this is not so much about the protocol level.

884
01:12:24,280 --> 01:12:27,920
If you want to upload whatever you want and create it as a smart contract, I'm not going

885
01:12:27,920 --> 01:12:31,440
to give myself permission to delete it just because of this issue.

886
01:12:31,440 --> 01:12:38,320
So it can exist on chain, but it would need to not be on the front end.

887
01:12:38,320 --> 01:12:43,200
And so figuring out a way to make this a self-sustaining thing.

888
01:12:43,200 --> 01:12:47,920
And if I forget that we would need a team of moderators is probably one of the challenges

889
01:12:47,920 --> 01:12:50,880
to consider.

890
01:12:50,880 --> 01:12:56,920
The thing with that is if you try to make a monetized token around reputation and you

891
01:12:56,920 --> 01:13:03,920
have people working for moderation to get that token, then not only do you have to fund

892
01:13:03,920 --> 01:13:11,040
the token itself and reward people for moderating, which is fine, but it would have to be a large

893
01:13:11,040 --> 01:13:18,960
enough market cap to not be subvertible by someone spending $10 to buy some.

894
01:13:18,960 --> 01:13:25,080
So it might be something that requires a time lock or a vesting of your reputation tokens

895
01:13:25,080 --> 01:13:29,200
so that someone couldn't attack it immediately, but they would have to attack it like over

896
01:13:29,200 --> 01:13:32,280
months and some time.

897
01:13:32,280 --> 01:13:35,280
Generally there are no, I don't think there are very many good solutions here that do

898
01:13:35,280 --> 01:13:37,840
not involve KYC.

899
01:13:37,840 --> 01:13:39,800
And even then.

900
01:13:39,800 --> 01:13:47,680
And you just try to raise the bar higher to attacking the moderation system.

901
01:13:47,680 --> 01:13:49,680
I think that's the best you can do.

902
01:13:49,680 --> 01:13:58,240
Or hire a bunch of moderators and give them ban power, over the front end at least.

903
01:13:58,240 --> 01:14:08,120
I'd be very curious to see the implementation details on that or whatever you have the perhaps

904
01:14:08,120 --> 01:14:13,400
or also if there's anything you might need in terms of testing, feel free to reach out,

905
01:14:13,400 --> 01:14:15,280
would be happy to contribute.

906
01:14:15,280 --> 01:14:21,440
I think conceptualizing boxes as a L1 primitive is one thing, but then conceptualizing this

907
01:14:21,440 --> 01:14:26,840
as a file system, you can potentially...

908
01:14:26,840 --> 01:14:32,840
Because the way I see it based on your description is an abstraction on top of boxes that simplifies

909
01:14:32,840 --> 01:14:40,400
interactions with on-chain data in general, and I think that's a really powerful primitive

910
01:14:40,400 --> 01:14:49,240
if built right and also provides a way for layman users to interact through web interface.

911
01:14:49,240 --> 01:14:54,040
I think there's a lot of opportunity there just from a perspective of building a protocol

912
01:14:54,040 --> 01:15:01,480
or if you want to achieve what is something in between when there you also have some features

913
01:15:01,480 --> 01:15:04,440
that potentially you would want to monetize.

914
01:15:04,440 --> 01:15:06,320
But yeah, thank you for describing it.

915
01:15:06,320 --> 01:15:12,920
I think this is certainly something that will benefit the builders in the community and

916
01:15:12,920 --> 01:15:15,840
just the ecosystem in general, I think.

917
01:15:15,840 --> 01:15:17,920
Yeah, let's please do the first by the way.

918
01:15:17,920 --> 01:15:23,240
The chain UI thing you mentioned, while it's not the first instance of box storage, I think

919
01:15:23,240 --> 01:15:28,960
it's the first public project that has the concept of storing the website's code in a

920
01:15:28,960 --> 01:15:29,960
box.

921
01:15:29,960 --> 01:15:34,560
I think they're limiting themselves to a single box there, I'm not 100% sure, but there is

922
01:15:34,560 --> 01:15:38,600
a size limitation to how much you can store in a chain UI, so I assume that's derived

923
01:15:38,600 --> 01:15:42,640
from that chain from a maximum box length.

924
01:15:42,640 --> 01:15:44,160
Oh yes, definitely.

925
01:15:44,160 --> 01:15:50,960
The reason why I didn't explicitly mention that, although I did mention them with regards

926
01:15:50,960 --> 01:15:55,220
to the web components and things like that is particularly that, right?

927
01:15:55,220 --> 01:16:00,920
Because it seems like despite the fact that you can pretty much store anything on the

928
01:16:00,920 --> 01:16:06,480
box storage, their approach was a lot more tailored and optimized for HTML files and

929
01:16:06,480 --> 01:16:11,720
artifacts that you may deal with when trying to display the web content.

930
01:16:11,720 --> 01:16:15,640
While in your case, I think it's a lot more generalized, right?

931
01:16:15,640 --> 01:16:21,760
And you're also talking about compressing data in different ways to limit the amount

932
01:16:21,760 --> 01:16:31,120
of information you can save on space as well, because boxes are cheap until they aren't,

933
01:16:31,120 --> 01:16:32,120
right?

934
01:16:32,120 --> 01:16:33,120
Until you get to a megabyte, right?

935
01:16:33,120 --> 01:16:37,640
Until you get to a megabyte and they're no longer cheap.

936
01:16:37,640 --> 01:16:44,520
So yeah, I think it's also quite powerful that you do approaching this in slightly more

937
01:16:44,520 --> 01:16:51,360
broad terms and I guess trying to aim for potentially having some sort of file system

938
01:16:51,360 --> 01:17:00,160
layer that is already powered by a quiet extensible primitive that's baked right into the L1.

939
01:17:00,160 --> 01:17:08,120
A box for one megabyte would be about 419 algo.

940
01:17:08,120 --> 01:17:14,800
So one concern that I don't need to concern myself with is video piracy on chain.

941
01:17:14,800 --> 01:17:15,800
Yeah.

942
01:17:15,800 --> 01:17:22,960
Oh yeah, I mean, you might have to be an absolute madman to store videos on chain in the box

943
01:17:22,960 --> 01:17:26,440
stores especially.

944
01:17:26,440 --> 01:17:37,000
But yeah, as we move towards decentralization in this very weird, I would say, era where

945
01:17:37,000 --> 01:17:41,800
everything is dominated by centralized solutions, where even the term open source by itself,

946
01:17:41,800 --> 01:17:48,320
I think is mostly an industry term that came in after real open source died off.

947
01:17:48,320 --> 01:17:51,760
If we're talking about public domain software.

948
01:17:51,760 --> 01:17:57,840
How do you think Algorand can generally help stigmatize the web 3 domain a little bit?

949
01:17:57,840 --> 01:18:05,600
Because I think adoption is one of the main ingredients in increasing the just general

950
01:18:05,600 --> 01:18:10,840
usefulness of blockchains because there is indeed a lot of real life applications where

951
01:18:10,840 --> 01:18:14,760
it does make sense even outside of the financial sector.

952
01:18:14,760 --> 01:18:17,160
But you need people building on this.

953
01:18:17,160 --> 01:18:24,320
And unfortunately, there's a lot of stigma around just cryptocurrency in general.

954
01:18:24,320 --> 01:18:30,660
In my opinion, I think it's mostly coming down to reducing a little bit on the amount

955
01:18:30,660 --> 01:18:35,600
of web 3 specific terminology because it is computer science.

956
01:18:35,600 --> 01:18:39,060
At the end of the day, there's a lot of things.

957
01:18:39,060 --> 01:18:44,320
Indeed the paradigm with smart contracts is very different to what modern software engineers

958
01:18:44,320 --> 01:18:45,320
might think about.

959
01:18:45,320 --> 01:18:48,680
It was the deal with cloud development and things like that.

960
01:18:48,680 --> 01:18:56,400
But what's in your opinion, one of the strategies that can potentially attract more people to

961
01:18:56,400 --> 01:19:01,480
this particular domain?

962
01:19:01,480 --> 01:19:07,560
So yeah, the blockchain reputation, the web 3 reputation right now is in the tatters.

963
01:19:07,560 --> 01:19:11,680
This kind of makes sense.

964
01:19:11,680 --> 01:19:16,080
It's ironic and unfortunate that a lot of that has to do with centralized solution that

965
01:19:16,080 --> 01:19:19,520
just happened to be selling cryptocurrencies.

966
01:19:19,520 --> 01:19:25,320
If they were selling potatoes or onions, then we wouldn't be calling potatoes and onions

967
01:19:25,320 --> 01:19:26,320
a scam.

968
01:19:26,320 --> 01:19:33,080
But the permissionless aspect of it and the anonymity or pseudonymity of it also lends

969
01:19:33,080 --> 01:19:37,280
itself to a lot of scams and maybe well-intentioned bubbles as well.

970
01:19:37,280 --> 01:19:48,640
Personally, I've been interested in this space for more than a decade now.

971
01:19:48,640 --> 01:19:53,680
So from a developer's point of view, the other thing is how interesting programmable money

972
01:19:53,680 --> 01:19:58,680
is, especially now that you have smart contracts and it's not just sending it from one account

973
01:19:58,680 --> 01:19:59,680
to the other.

974
01:19:59,680 --> 01:20:07,200
It is quite fascinating to write what is essentially Python or TypeScript and it can manage split

975
01:20:07,200 --> 01:20:12,240
payments or royalties or whatever it is that you would want to do.

976
01:20:12,240 --> 01:20:18,520
And also the aspect of having a neutral and trusted environment where this is going to

977
01:20:18,520 --> 01:20:19,520
run.

978
01:20:19,520 --> 01:20:26,240
So Teal is not ideal for readability and that's something ideal would be source-visible-on-chain

979
01:20:26,240 --> 01:20:28,960
and higher level, but you can't have everything.

980
01:20:28,960 --> 01:20:35,280
But the point is that it's an environment that will execute the code that you published

981
01:20:35,280 --> 01:20:37,440
in exactly that way.

982
01:20:37,440 --> 01:20:44,560
And this is not really something that you can replicate outside of blockchain.

983
01:20:44,560 --> 01:20:49,960
You're usually trusting a single party to run that code for you to be the escrow account

984
01:20:49,960 --> 01:20:58,480
and that kind of power maybe there should be a way to have this kind of trustless execution.

985
01:20:58,480 --> 01:21:06,400
So figuring out what blockchain is good for and figuring out the pragmatic split between

986
01:21:06,400 --> 01:21:10,040
decentralization and lawfulness, let's say.

987
01:21:10,040 --> 01:21:16,960
While I do subscribe to the cypherpunk ideals myself, like if we are realistic, then there

988
01:21:16,960 --> 01:21:27,240
needs to be some kind of, if not regulation, then at least some kind of law around scamming

989
01:21:27,240 --> 01:21:30,640
and stealing and all of that stuff.

990
01:21:30,640 --> 01:21:34,720
Also everyone's an anarchist until their house is broken into and then they're crying for

991
01:21:34,720 --> 01:21:40,080
the police, which happened to a lot of us in February, March, April and May of this

992
01:21:40,080 --> 01:21:43,440
year.

993
01:21:43,440 --> 01:21:50,600
So yeah, figure out what works best, figure out the best balance of centralized and decentralized

994
01:21:50,600 --> 01:21:59,920
and the reputation will probably improve with the next cycle, right?

995
01:21:59,920 --> 01:22:06,280
Which is, I guess, some people might say that it's right around the corner.

996
01:22:06,280 --> 01:22:11,000
From my side though, I don't really at this point, don't really look into the trends

997
01:22:11,000 --> 01:22:13,200
in the cycles in that manner.

998
01:22:13,200 --> 01:22:18,240
It's more of a just general excitement about what's to come next year in terms of features

999
01:22:18,240 --> 01:22:21,560
that Algorand is going to be adding and we'll see.

1000
01:22:21,560 --> 01:22:23,280
On the other hand, there is also...

1001
01:22:23,280 --> 01:22:24,280
Sorry, go ahead.

1002
01:22:24,280 --> 01:22:34,600
I was going to say that it does impact the market size and the community size.

1003
01:22:34,600 --> 01:22:40,360
So one aspect is, okay, my own personal algo stash is down or Ethereum stash or whatever,

1004
01:22:40,360 --> 01:22:44,440
but the other aspect is there were a thousand people here, now there's 300.

1005
01:22:44,440 --> 01:22:51,680
So that is a bit of a bummer, but my silver lining here is to see, as mentioned before,

1006
01:22:51,680 --> 01:22:55,640
Inc. and the foundation working on the right things largely.

1007
01:22:55,640 --> 01:23:00,800
There really are super exciting things around the corner, maybe latest year or early next

1008
01:23:00,800 --> 01:23:06,480
year with the dynamic Lambda and super short runtimes and with peer to peer.

1009
01:23:06,480 --> 01:23:10,960
And even in the small stuff that they are still working on, like the boxer size and

1010
01:23:10,960 --> 01:23:13,000
the box supply stuff.

1011
01:23:13,000 --> 01:23:14,640
Yeah.

1012
01:23:14,640 --> 01:23:25,200
As it happens with a lot of the episodes so far, I'd really like to ask some of the closing

1013
01:23:25,200 --> 01:23:30,640
questions, which in this case, I think there is just one potential question that we got

1014
01:23:30,640 --> 01:23:36,240
from the community so far, which we can just briefly touch on before the final question

1015
01:23:36,240 --> 01:23:38,400
for the episode.

1016
01:23:38,400 --> 01:23:47,920
So someone asked yesterday on the ask.osu.malgo, in your opinion, what's the top one best and

1017
01:23:47,920 --> 01:23:52,000
worst thing event that happened in this ecosystem this year?

1018
01:23:52,000 --> 01:23:58,320
Which I think the answers might be obvious for some people, but still worth, I guess,

1019
01:23:58,320 --> 01:24:00,320
getting your opinion on.

1020
01:24:00,320 --> 01:24:01,360
Right.

1021
01:24:01,360 --> 01:24:07,000
The worst would probably have to be the my algo hack situation.

1022
01:24:07,000 --> 01:24:14,560
By a mile, the community was already thinning out in the bear market, which is to be expected.

1023
01:24:14,560 --> 01:24:16,720
And that kind of came out of nowhere.

1024
01:24:16,720 --> 01:24:20,440
It was a professional hit, 100%.

1025
01:24:20,440 --> 01:24:24,920
There's so many algo parts from the very first wave of the attack still on chain, think to

1026
01:24:24,920 --> 01:24:28,480
the tune of more than 8 million, that still hasn't moved.

1027
01:24:28,480 --> 01:24:33,080
And yet they moved on to hit thousands of smaller accounts.

1028
01:24:33,080 --> 01:24:40,000
This entire thing doesn't really make sense as a financially motivated attack.

1029
01:24:40,000 --> 01:24:41,400
But okay, yeah.

1030
01:24:41,400 --> 01:24:46,960
So the worst thing would have to be the my algo hack because aside from the financial

1031
01:24:46,960 --> 01:24:53,000
losses that people incurred, it also really, really hit the community size and the confidence

1032
01:24:53,000 --> 01:24:57,600
in Algorand, even though Algorand itself wasn't really hosting my algo.com.

1033
01:24:57,600 --> 01:25:07,760
As for best, I can't really single out a single spectacular event, but I've basically already

1034
01:25:07,760 --> 01:25:13,880
addressed this as the reasons why I'm still bullish on Algorand, which is that I see the

1035
01:25:13,880 --> 01:25:19,920
people involved working on the right things, at least according to me, and their hearts

1036
01:25:19,920 --> 01:25:24,080
still seem to be in it.

1037
01:25:24,080 --> 01:25:26,560
Same question back to you, best and worst.

1038
01:25:26,560 --> 01:25:34,840
Yeah, obviously I think the my algo hack was a huge blow in terms of, and I guess this

1039
01:25:34,840 --> 01:25:46,080
might be rather the personal manner, but after getting to maybe like, might be news for some

1040
01:25:46,080 --> 01:25:51,720
listeners, but like I am happy to like inform that my sort of escape from big enterprises

1041
01:25:51,720 --> 01:25:57,520
has been a success so far and I do now have the ability to contribute and work full time

1042
01:25:57,520 --> 01:26:00,400
on the Algorand ecosystem explicitly.

1043
01:26:00,400 --> 01:26:09,520
And this includes the contributions to AlgoKit, but I'd say personal opinions about learning

1044
01:26:09,520 --> 01:26:18,120
a bit more intricate details about how things are being managed and organized and what people

1045
01:26:18,120 --> 01:26:23,800
care about and worry about within Algorand Inc or foundation or the partners who are

1046
01:26:23,800 --> 01:26:25,560
building the tooling.

1047
01:26:25,560 --> 01:26:28,960
I think the intent is certainly in place.

1048
01:26:28,960 --> 01:26:37,280
There's a lot of people who really truly care about the tech and doing its best to basically

1049
01:26:37,280 --> 01:26:42,200
tackle the main challenges, which in my case is adoption.

1050
01:26:42,200 --> 01:26:48,520
One of the challenges that I personally am committed to right now and trying to pretty

1051
01:26:48,520 --> 01:26:54,640
much do my best in terms of improving the developer experience and things around it.

1052
01:26:54,640 --> 01:27:02,480
But I'd say one of the best things this year so far was just confirming a lot of the things

1053
01:27:02,480 --> 01:27:10,280
I had my opinions on before actually being able to learn about and get to know some people

1054
01:27:10,280 --> 01:27:12,280
in the community a lot better.

1055
01:27:12,280 --> 01:27:13,880
Obviously it's not a financial advice.

1056
01:27:13,880 --> 01:27:18,240
I can't really promise anything, but one thing for sure is there's a lot of engineers who

1057
01:27:18,240 --> 01:27:21,800
are just working their asses off every day.

1058
01:27:21,800 --> 01:27:28,480
And it's just great to still be able to be within that environment and build something

1059
01:27:28,480 --> 01:27:35,240
that I think is potentially one of the most scalable decentralized protocols out there.

1060
01:27:35,240 --> 01:27:38,800
But we really need to polish out the dev experience around it.

1061
01:27:38,800 --> 01:27:44,040
And yeah, can't wait to see what's going to be the perception around some of the tooling

1062
01:27:44,040 --> 01:27:48,840
once a lot of the exciting things on the AlgoKit site, for example, are going to be out.

1063
01:27:48,840 --> 01:27:51,120
Sorry, I'm going on a tangent at this point a bit.

1064
01:27:51,120 --> 01:27:57,520
But another thing is obviously bear markets are a bad thing, but it did showed a lot of

1065
01:27:57,520 --> 01:28:04,760
real intentions behind a lot of people who may have had a look around being a good actor

1066
01:28:04,760 --> 01:28:10,400
in the ecosystem, but it's the great filter in some sense as well.

1067
01:28:10,400 --> 01:28:13,440
It shows you who the fair weather friends are.

1068
01:28:13,440 --> 01:28:17,560
It shows you who are the actual people in the community who are there for the community

1069
01:28:17,560 --> 01:28:23,200
and care about the tech and expanding it and attracting more developers versus who were

1070
01:28:23,200 --> 01:28:29,680
there for just the money perhaps or maybe getting some sort of weird internet fame.

1071
01:28:29,680 --> 01:28:31,520
How would you call it?

1072
01:28:31,520 --> 01:28:37,840
It's a whole other topic that's going to stretch this episode a little bit more.

1073
01:28:37,840 --> 01:28:42,340
But one thing I believe, so the second worst thing that can happen with blockchain is it

1074
01:28:42,340 --> 01:28:45,800
goes mainstream big time as it is right now.

1075
01:28:45,800 --> 01:28:49,720
Because yes, the stuff that we said about regulations and law and order and everything

1076
01:28:49,720 --> 01:28:58,640
is kind of required, but also anonymity and privacy is like privacy is a basic human right.

1077
01:28:58,640 --> 01:29:04,040
And right now there's very few blockchains that offer actual privacy.

1078
01:29:04,040 --> 01:29:09,720
And so if tomorrow morning we woke up and everyone had a blockchain account, that wouldn't

1079
01:29:09,720 --> 01:29:15,880
necessarily be a good thing based on the state of blockchain right now with everything being

1080
01:29:15,880 --> 01:29:17,640
super public, right?

1081
01:29:17,640 --> 01:29:23,480
I don't know that you would want your entire purchasing history not only being available

1082
01:29:23,480 --> 01:29:29,400
to corporations via other corporations and banks, but to everyone in every CD bar that

1083
01:29:29,400 --> 01:29:34,240
you go and pay with some crypto, right?

1084
01:29:34,240 --> 01:29:44,180
So hopefully an evolution with something that blends privacy into blockchain before everyone

1085
01:29:44,180 --> 01:29:49,080
has a blockchain wallet will happen as well.

1086
01:29:49,080 --> 01:29:52,880
Oh yeah, I absolutely agree on that point.

1087
01:29:52,880 --> 01:29:55,320
It's a double edged sword, right?

1088
01:29:55,320 --> 01:30:01,800
It's important not to forget that the blockchain is still a technology and any technology can,

1089
01:30:01,800 --> 01:30:06,280
depending on which actors are using it, could be used for many different intents.

1090
01:30:06,280 --> 01:30:11,520
And to be, I guess, a bit more pragmatic in this case, there are obviously absolutely

1091
01:30:11,520 --> 01:30:20,000
no indicators that it's always going to be used for good, just as with any technology.

1092
01:30:20,000 --> 01:30:28,280
So I know there has been a lot of talk in the community as well that Celui is also caring

1093
01:30:28,280 --> 01:30:31,440
a lot about privacy in this regard.

1094
01:30:31,440 --> 01:30:36,600
I assume this is very long-term though, but I would be curious to see what are the options

1095
01:30:36,600 --> 01:30:42,800
that are there for enhancing or just introducing the notion of privacy into Algorand itself.

1096
01:30:42,800 --> 01:30:49,680
But on the bigger scale of things, yeah, I think it's one of the key ingredients for

1097
01:30:49,680 --> 01:31:01,120
just survivability of a particular, whether it has ability to have privacy in general.

1098
01:31:01,120 --> 01:31:04,880
The other aspect is, of course, if the tech is good, someone like BlackRock is going to

1099
01:31:04,880 --> 01:31:11,560
come in and buy your chain and reverse engineer it and run it privately and have some, I don't

1100
01:31:11,560 --> 01:31:17,280
know, central bank currencies that has smart contracts with clawbacks for every single

1101
01:31:17,280 --> 01:31:18,280
citizen.

1102
01:31:18,280 --> 01:31:21,000
So it's absolutely dystopian scenario.

1103
01:31:21,000 --> 01:31:25,600
And once again, same tech, but completely different approach to using it.

1104
01:31:25,600 --> 01:31:31,960
So it's going to be interesting to see because I think it's still, despite this being over

1105
01:31:31,960 --> 01:31:35,720
the span of many decades, just affecting the society in many ways.

1106
01:31:35,720 --> 01:31:42,200
But we'll see what's the team Byzantine fault tolerance going to show in this regard.

1107
01:31:42,200 --> 01:31:50,800
But also the proof of work stuff shows that you can have an anonymous people who are mining.

1108
01:31:50,800 --> 01:31:53,640
You just know their hardware and not even that.

1109
01:31:53,640 --> 01:31:58,880
And so in theory, they could spend their Bitcoin or Monero to do whatever.

1110
01:31:58,880 --> 01:32:07,920
And at least in Bitcoin's case, the concerns about terrorism and all the bad things as

1111
01:32:07,920 --> 01:32:16,640
a percentage of total cryptocurrency transactions are very regularly shown to be super overblown.

1112
01:32:16,640 --> 01:32:23,840
There was a very recent analysis by Chainalysis to address some concerns that Hamas was being

1113
01:32:23,840 --> 01:32:31,120
funded to like a tune of billions, but in fact it was a shared wallet and the exposure,

1114
01:32:31,120 --> 01:32:35,020
both inflows and outflows there was less than 1%.

1115
01:32:35,020 --> 01:32:38,880
So yeah.

1116
01:32:38,880 --> 01:32:39,880
And that was what?

1117
01:32:39,880 --> 01:32:40,880
Bitcoin?

1118
01:32:40,880 --> 01:32:43,880
Ethereum, I believe.

1119
01:32:43,880 --> 01:32:44,880
Ethereum.

1120
01:32:44,880 --> 01:32:45,880
Interesting.

1121
01:32:45,880 --> 01:32:46,880
Yeah.

1122
01:32:46,880 --> 01:32:51,760
But I guess that's generally the sentiment I think.

1123
01:32:51,760 --> 01:32:58,320
And generally just my mindset at the moment is more of a, you know, being focused on building

1124
01:32:58,320 --> 01:33:03,880
things rather than trying to speculate on the potential outcomes because it's just too

1125
01:33:03,880 --> 01:33:07,600
many variables in the world right now.

1126
01:33:07,600 --> 01:33:08,600
Yeah, for sure.

1127
01:33:08,600 --> 01:33:10,600
Too easy to get carried away.

1128
01:33:10,600 --> 01:33:11,600
Yeah.

1129
01:33:11,600 --> 01:33:18,200
I'm genuinely excited to see what's going to come out over the next six to nine months

1130
01:33:18,200 --> 01:33:21,920
and where the consensus incentive stuff leads.

1131
01:33:21,920 --> 01:33:25,400
Likewise.

1132
01:33:25,400 --> 01:33:32,520
As a closing note, any particular advice, and I'm usually asking this for people who

1133
01:33:32,520 --> 01:33:38,240
are curious to get into or venture into blockchain development, but we can potentially take a

1134
01:33:38,240 --> 01:33:43,960
broader scope in this case, but any particular advice you might give to aspiring software

1135
01:33:43,960 --> 01:33:50,440
engineers who are looking to venture, say even something more broader scope, like just

1136
01:33:50,440 --> 01:33:56,040
the domain of systems design or distributed systems, because it doesn't always necessarily

1137
01:33:56,040 --> 01:34:01,840
imply blockchain, right?

1138
01:34:01,840 --> 01:34:08,400
I think for blockchain, the advice would be different than distributed systems in general

1139
01:34:08,400 --> 01:34:14,280
because of the downside of losing your own money and other people's money, even worse.

1140
01:34:14,280 --> 01:34:19,720
So for blockchain, my advice would be to not start with a smart contract.

1141
01:34:19,720 --> 01:34:22,520
They are brutal.

1142
01:34:22,520 --> 01:34:27,220
If they hold any significant amount of money, it's going to be an implicit bug bounty to

1143
01:34:27,220 --> 01:34:30,480
figure out the bug that you wrote.

1144
01:34:30,480 --> 01:34:31,880
I have written a bug.

1145
01:34:31,880 --> 01:34:37,480
It was not exploited, thankfully, and the amounts were very small, but that doesn't really mean

1146
01:34:37,480 --> 01:34:38,480
anything.

1147
01:34:38,480 --> 01:34:44,800
So I would not start with a smart contract, at least to be deployed to mainnet.

1148
01:34:44,800 --> 01:34:51,080
I would start with as boring as it might be as advice, getting familiar with the protocol

1149
01:34:51,080 --> 01:34:52,800
in depth.

1150
01:34:52,800 --> 01:34:59,420
And if you can't be asked to do that, then work in the web 2.5 space, which I would call

1151
01:34:59,420 --> 01:35:05,820
anything that isn't actually the backend, isn't actually a smart contract or on chain.

1152
01:35:05,820 --> 01:35:11,560
Maybe it would be something like flow.algo.surf, which is a blockchain analytics tool that

1153
01:35:11,560 --> 01:35:15,640
I've written for Algorand where you just display web 3 data.

1154
01:35:15,640 --> 01:35:21,000
Maybe just sending NFTs around, maybe that's web 2.5, maybe that's web 3.

1155
01:35:21,000 --> 01:35:27,600
But generally I'd say to start simple and especially in a blockchain that isn't too

1156
01:35:27,600 --> 01:35:34,840
crowded from a developer point of view, there's always space to just show data from the chain

1157
01:35:34,840 --> 01:35:37,880
that isn't done.

1158
01:35:37,880 --> 01:35:44,560
So recently we had a chain trail launch on Algorand within the last five to six months,

1159
01:35:44,560 --> 01:35:45,560
I believe.

1160
01:35:45,560 --> 01:35:51,180
That's just focusing on TPS and identifying who is using the chain at any given block

1161
01:35:51,180 --> 01:35:53,600
or any given time segment.

1162
01:35:53,600 --> 01:35:59,920
There's AlgoGator, which is mostly creating dashboards for you out of DeFi opportunities.

1163
01:35:59,920 --> 01:36:04,040
And that's largely a read-only state of the blockchain.

1164
01:36:04,040 --> 01:36:11,040
There's a lot of stuff to figure out, but it is genuinely interesting to play with programmable

1165
01:36:11,040 --> 01:36:15,720
money, but do it responsibly to yourself first of all, and then to your users.

1166
01:36:15,720 --> 01:36:23,400
So another really, really good idea is to, if you are going to venture into smart contracts,

1167
01:36:23,400 --> 01:36:28,040
is to read post mortems of previous hacks.

1168
01:36:28,040 --> 01:36:34,360
Figuring out how other professional developers failed in implementing something on this chain

1169
01:36:34,360 --> 01:36:41,520
should be required reading before you do anything big with the money on that chain or just generally

1170
01:36:41,520 --> 01:36:45,200
in chains.

1171
01:36:45,200 --> 01:36:50,800
And on that side also, I'm not sure I can share much information yet, but there will

1172
01:36:50,800 --> 01:36:57,520
be things that AlgoGate will simplify access to in regards to potentially at least catching

1173
01:36:57,520 --> 01:37:02,080
the most obvious rookie mistakes you might make in smart contract development.

1174
01:37:02,080 --> 01:37:03,440
But yeah, I absolutely agree.

1175
01:37:03,440 --> 01:37:09,560
It's usually a great source of learning when it comes to exploits in smart contracts.

1176
01:37:09,560 --> 01:37:14,240
It's just a slightly different paradigm of software development you have to think about

1177
01:37:14,240 --> 01:37:18,000
because yeah, indeed you're dealing with someone else's money.

1178
01:37:18,000 --> 01:37:22,720
There's significantly less mutability than you expect from it.

1179
01:37:22,720 --> 01:37:29,800
And yeah, it's just generally something you have to approach with a lot of care and indulgence

1180
01:37:29,800 --> 01:37:37,120
before ever deploying something that other people can chat or interact with.

1181
01:37:37,120 --> 01:37:39,640
But with that, thank you for great advice.

1182
01:37:39,640 --> 01:37:43,360
And very, very excited to interact with you.

1183
01:37:43,360 --> 01:37:48,600
I'm still in a bit of a disbelief that I'm already at episode 19.

1184
01:37:48,600 --> 01:37:55,280
This whole ordeal started just as a way to just chat with great people, engineers on

1185
01:37:55,280 --> 01:37:58,440
topics that I personally find a lot of passion in.

1186
01:37:58,440 --> 01:38:01,040
And yeah, it's amazing to have you on the episode.

1187
01:38:01,040 --> 01:38:02,040
Thanks for coming.

1188
01:38:02,040 --> 01:38:09,840
I'm hoping we can have one maybe doing a slightly deeper and I guess focused dive on the platform

1189
01:38:09,840 --> 01:38:12,800
around the boxes with the Base32 fund.

1190
01:38:12,800 --> 01:38:17,160
It's best of luck with the challenge for the moderation around it.

1191
01:38:17,160 --> 01:38:22,280
I think that solving that one is going to be quite interesting to see.

1192
01:38:22,280 --> 01:38:23,560
But yeah, other than that.

1193
01:38:23,560 --> 01:38:24,560
Thank you.

1194
01:38:24,560 --> 01:38:25,560
Thank you very much for the invite.

1195
01:38:25,560 --> 01:38:28,440
I enjoyed our chat immensely.

1196
01:38:28,440 --> 01:38:32,360
As I said, your podcast is one of my favorites.

1197
01:38:32,360 --> 01:38:34,840
Thanks very much for the opportunity to be here.

1198
01:38:34,840 --> 01:38:36,820
Stay tuned for episode 20.

1199
01:38:36,820 --> 01:38:41,840
That's going to be a special episode and we'll have to potentially make the very first episode

1200
01:38:41,840 --> 01:38:44,000
we'll have multiple guests on it.

1201
01:38:44,000 --> 01:38:46,960
But that might come after quite some time.

1202
01:38:46,960 --> 01:39:16,080
But once again, thanks for staying with us.