1
00:00:00,433 --> 00:00:02,135
Hello everyone, and welcome back
2
00:00:02,135 --> 00:00:05,672
to KPMG in Canada's
State of Digital Assets podcast series.
3
00:00:05,972 --> 00:00:08,675
As always, I'm your host, Adam Rodricks,
and today
4
00:00:08,675 --> 00:00:12,879
we will be focusing on the evolution
of staking, risks, rewards and innovations
5
00:00:12,879 --> 00:00:15,215
with special guests,
Ben and Reza from Figment
6
00:00:15,215 --> 00:00:18,218
working in the field of blockchain
technology and staking.
7
00:00:18,718 --> 00:00:21,888
Starting with our KPMG participants,
I am so pleased to welcome back
8
00:00:21,888 --> 00:00:24,891
our Digital Asset Center of Excellence.
9
00:00:28,094 --> 00:00:28,628
Hi everyone!
10
00:00:28,628 --> 00:00:29,863
My name is Kunal Bhasin.
11
00:00:29,863 --> 00:00:33,933
I’m a partner with KPMG in Canada,
based in Toronto.
12
00:00:34,334 --> 00:00:38,138
I head our Digital Assets
Center of Excellence and focus
13
00:00:38,138 --> 00:00:42,008
a lot on our efforts on different aspects,
including staking.
14
00:00:42,008 --> 00:00:45,011
So happy to be here
and having this discussion today.
15
00:00:45,278 --> 00:00:47,247
Thank you Kunal.
And Adam.
16
00:00:47,247 --> 00:00:48,481
And my name is George Djuric.
17
00:00:48,481 --> 00:00:51,518
I'm a manager with our Digital Assets
Center of Excellence, also
18
00:00:51,518 --> 00:00:56,189
based out of Toronto, and I focus on
all things crypto related at the firm.
19
00:00:56,189 --> 00:00:59,325
That typically entails working
with three different types of clients
20
00:00:59,692 --> 00:01:04,798
your traditional institutional types,
your crypto native types, and regulators.
21
00:01:05,265 --> 00:01:08,301
As it relates to staking,
we've been seeing a lot more institutional
22
00:01:08,334 --> 00:01:12,806
interest in this area, so really excited
to dive into it with the Figment team.
23
00:01:14,274 --> 00:01:15,909
Fantastic
Thank you both for
24
00:01:15,909 --> 00:01:19,646
being here, and we are beyond excited
to welcome our guests from Figment.
25
00:01:19,913 --> 00:01:22,982
Could you each start by please
introducing yourselves as well?
26
00:01:22,982 --> 00:01:25,318
Maybe I'll go to Ben first.
27
00:01:25,318 --> 00:01:27,353
Hey folks.
So as mentioned, my name is Ben.
28
00:01:27,353 --> 00:01:28,721
Ben Thalman.
29
00:01:28,721 --> 00:01:31,357
I'm a senior protocol
specialist at Figment.
30
00:01:31,357 --> 00:01:35,128
I cover the Ethereum ecosystem,
so everything that happens on the base
31
00:01:35,128 --> 00:01:38,498
layer of Ethereum is very much of interest
to me.
We've got an update coming,
32
00:01:39,365 --> 00:01:41,067
early next year called Petra.
33
00:01:41,067 --> 00:01:42,802
But then, of course, everything
built on top.
34
00:01:42,802 --> 00:01:46,072
So you've heard things like MEV
maximalist, tractable value,
35
00:01:46,573 --> 00:01:48,575
scaling efforts, Altuz staking.
36
00:01:48,575 --> 00:01:51,511
All of that is in my wheelhouse.
37
00:01:51,511 --> 00:01:54,481
And before joining Figment,
I was in TradFi for about ten years.
38
00:01:54,914 --> 00:01:55,982
Hello everyone.
39
00:01:55,982 --> 00:01:58,952
I'm really happy to be here.
I'm Reza from Figment.
40
00:01:59,119 --> 00:02:01,488
I am part of the product team, and
41
00:02:02,622 --> 00:02:04,824
my main focus at Figment is
42
00:02:04,824 --> 00:02:09,262
our tier zero networks,
which are Ethereum and Solana.
43
00:02:09,262 --> 00:02:15,502
I work very closely with Ben,
and we build stuff to make sure
44
00:02:15,502 --> 00:02:19,639
that our operations are smooth
and, are excellent.
45
00:02:21,674 --> 00:02:22,375
Fantastic.
46
00:02:22,375 --> 00:02:22,942
Thank you both
47
00:02:22,942 --> 00:02:26,679
so much for being here today.
Now,
we talked a little bit about what you do.
48
00:02:26,980 --> 00:02:30,150
Can you give us a brief introduction
as to what Figment does?
49
00:02:30,450 --> 00:02:33,453
Figment is an institutional
staking service provider.
50
00:02:33,853 --> 00:02:37,157
We offer staking infrastructure
on over three dozen networks.
51
00:02:38,191 --> 00:02:40,059
Our focus is mainly institutional.
52
00:02:40,059 --> 00:02:44,164
We're non-custodial, so we don't actually
take control of our customers tokens.
53
00:02:44,898 --> 00:02:47,567
You know, as Reza mentioned in his intro,
54
00:02:47,567 --> 00:02:50,603
Ethereum and Solana
are some of our larger networks
55
00:02:50,603 --> 00:02:53,940
that we focus on.
But as I say, we're on
something like 40 networks.
56
00:02:54,841 --> 00:02:56,342
and that's specifically for staking.
57
00:02:56,342 --> 00:02:59,245
We also offer some ancillary services.
58
00:02:59,245 --> 00:03:02,749
So, I think all told, we're probably on,
I don't know, close
59
00:03:02,749 --> 00:03:03,783
to running the infrastructure
60
00:03:03,783 --> 00:03:07,954
on close to 100 networks, but just around
40 of those are specifically for staking.
61
00:03:09,956 --> 00:03:10,957
Thanks so much, Ben.
62
00:03:10,957 --> 00:03:11,491
You know,
63
00:03:11,491 --> 00:03:13,026
you mentioned staking so many times.
64
00:03:13,026 --> 00:03:14,928
I'm going to have to take it
back to the beginning.
65
00:03:14,928 --> 00:03:18,031
Can you define staking and explain
its role in validating
66
00:03:18,031 --> 00:03:21,034
transactions
in a proof of stake blockchain?
67
00:03:21,167 --> 00:03:22,202
Absolutely.
68
00:03:22,202 --> 00:03:24,871
So, you know, I think from a very like 101
69
00:03:24,871 --> 00:03:27,840
basic understanding,
the way I like to think about staking
70
00:03:28,141 --> 00:03:32,412
is that it's effectively an agreement
between a token holder and a protocol.
71
00:03:32,946 --> 00:03:37,150
And so, the idea is if I'm a token holder
and I want to get involved with staking,
72
00:03:37,483 --> 00:03:41,721
I will perform certain tasks on
behalf of the network like Ethereum.
73
00:03:41,988 --> 00:03:43,790
And by the way, it is just an aside.
74
00:03:43,790 --> 00:03:45,858
Everything I say is probably going
to relate back to Ethereum.
75
00:03:45,858 --> 00:03:48,228
So heavy Ethereum references coming.
76
00:03:48,228 --> 00:03:50,563
But essentially,
I think of it like an agreement.
77
00:03:50,563 --> 00:03:54,567
Okay, so if I perform
the task as expected, I will get a reward.
78
00:03:54,734 --> 00:03:58,371
And that's what Ethereum or the protocol
kind of promises to me.
79
00:03:58,605 --> 00:04:02,175
And I promise to perform the tasks
appropriately.
80
00:04:02,542 --> 00:04:07,113
On Ethereum, that means I will test
correctly and in a timely manner.
81
00:04:07,247 --> 00:04:08,681
As an example,
82
00:04:08,681 --> 00:04:11,184
the whole issue with the state, the tokens
83
00:04:11,184 --> 00:04:14,187
that I put up, I'm essentially agreeing
84
00:04:14,454 --> 00:04:17,890
that I give Ethereum access to my tokens
for breaking rules.
85
00:04:17,890 --> 00:04:20,593
In other words,
they can take some of those tokens away.
86
00:04:20,593 --> 00:04:23,796
So again, I mentioned the timeliness
and correctness of an attestation.
87
00:04:24,264 --> 00:04:27,267
If I get that wrong,
some of my tokens will be taken away.
88
00:04:27,300 --> 00:04:30,637
And if I engage in malicious behaviour,
if I attempt to attack the network,
89
00:04:31,738 --> 00:04:33,172
even more tokens will be taken away.
90
00:04:33,172 --> 00:04:36,643
So those are a couple of examples,
but a high level or a 101, I think of it
91
00:04:36,643 --> 00:04:39,646
as an agreement between the token holder
and the protocol.
92
00:04:39,779 --> 00:04:40,380
Got it.
93
00:04:40,380 --> 00:04:43,650
And how does staking differ
from the proof of work consensus mechanism
94
00:04:43,650 --> 00:04:46,653
used by Bitcoin
and other cryptocurrencies?
95
00:04:46,953 --> 00:04:48,421
Great question.
96
00:04:48,421 --> 00:04:50,790
So, I like analogies,
especially from a 1 to 1 level.
97
00:04:50,790 --> 00:04:53,960
So, when I think about a proof
of stake versus proof of work.
98
00:04:54,394 --> 00:04:57,397
For proof of work,
I like the analogy of a race.
99
00:04:57,463 --> 00:04:59,332
And for proof of stake, I like a lottery.
100
00:04:59,332 --> 00:05:02,502
So, when you think about proof of work,
it's a lot like a race.
101
00:05:02,969 --> 00:05:06,739
Miners are racing each other
and the first miner to get over the finish
102
00:05:06,739 --> 00:05:11,311
line gets to produce a block, and
the block is just a set of transactions.
103
00:05:11,311 --> 00:05:12,445
So, you know, to
104
00:05:12,445 --> 00:05:16,382
tie back to a real world example, and
you can think of logging on to your bank
105
00:05:16,683 --> 00:05:18,918
and you see a bunch of transactions
that have happened,
106
00:05:18,918 --> 00:05:20,820
and you can see how your balances changed.
107
00:05:20,820 --> 00:05:22,622
Now obviously, the bank is centralized.
108
00:05:22,622 --> 00:05:24,691
We're talking about decentralization,
109
00:05:24,691 --> 00:05:27,660
but that's a helpful analogy to kind of
think of a block of transactions.
110
00:05:28,261 --> 00:05:31,731
So again, thinking about proof of work,
think of a race.
111
00:05:32,131 --> 00:05:34,367
What's actually happening
obviously is not a physical race,
112
00:05:34,367 --> 00:05:38,671
but there is a race between miners
and they're competing on essentially
113
00:05:38,671 --> 00:05:42,742
what boils down to a puzzle that they need
to solve using computational resources.
114
00:05:43,076 --> 00:05:45,778
And the first, again,
the first one to win that
115
00:05:45,778 --> 00:05:48,781
race gets to build
the next block on the chain.
116
00:05:48,915 --> 00:05:51,551
Now, I mentioned
proof of stake is more like a lottery.
117
00:05:51,551 --> 00:05:55,755
So, you can think of every stake
or validator on Ethereum, let's say
118
00:05:56,122 --> 00:05:57,123
as a lottery ticket.
119
00:05:58,191 --> 00:06:00,960
Every
12 seconds, a new proposer is chosen.
120
00:06:00,960 --> 00:06:03,696
So, in other words,
a lottery ticket is selected
121
00:06:03,696 --> 00:06:06,699
and whoever has that ticket
gets to propose the block.
122
00:06:07,500 --> 00:06:10,503
Now, a little bit of a nuance here,
123
00:06:10,503 --> 00:06:13,740
in terms of the probability of
being chosen on a proof of stake network
124
00:06:13,740 --> 00:06:17,910
to propose the next block of transactions,
it's proportional to your state.
125
00:06:18,277 --> 00:06:21,280
So, you can think of this as someone
who buys more lottery tickets than someone
126
00:06:21,280 --> 00:06:25,151
else, will have a higher likelihood
of being chosen to propose the block.
127
00:06:25,518 --> 00:06:28,221
But that's basically from a high level,
128
00:06:28,221 --> 00:06:30,423
stake is determining
who gets to propose the next block.
129
00:06:30,423 --> 00:06:33,426
Whereas on proof of work, it's
whoever wins that
130
00:06:34,394 --> 00:06:37,397
computer algorithm,
whoever solves that puzzle first.
131
00:06:37,830 --> 00:06:41,834
And if I can just add to that as well and
build off of what Ben is explaining here.
132
00:06:41,834 --> 00:06:45,438
One of the key differences
between the two consensus mechanism is
133
00:06:46,372 --> 00:06:47,640
energy intensiveness.
134
00:06:47,640 --> 00:06:51,511
So typically, proof of stake consensus
mechanisms
135
00:06:52,178 --> 00:06:55,448
produces far less energy
than proof of work systems.
136
00:06:55,848 --> 00:06:59,452
And so, it's typically been positioned
as a more and better
137
00:06:59,552 --> 00:07:02,522
environmentally friendly
consensus mechanism.
138
00:07:02,955 --> 00:07:06,993
And I think what a lot of people
forget as well is that Ethereum, prior
139
00:07:06,993 --> 00:07:11,364
to September 2022, is actually operating
on a proof of work model,
140
00:07:11,898 --> 00:07:15,768
and they had moved over to proof of stake
only two years ago.
141
00:07:15,768 --> 00:07:17,837
And I think a lot of folks forget that
142
00:07:17,837 --> 00:07:20,973
it's only been two years
since this has happened, and today
143
00:07:21,541 --> 00:07:25,711
I believe it's a little over
25% of all Ether is staked currently,
144
00:07:26,112 --> 00:07:29,315
which is about $90 billion of value
securing this network.
145
00:07:29,315 --> 00:07:33,219
So, I think that just underscores
the growing confidence in proof of stake
146
00:07:33,219 --> 00:07:34,053
systems as well.
147
00:07:35,555 --> 00:07:38,558
To add to Ben’s great analogy
148
00:07:39,425 --> 00:07:42,061
of race versus lottery.
149
00:07:42,061 --> 00:07:44,764
The caveats here
that this lottery is not passive.
150
00:07:44,764 --> 00:07:47,133
It's not that, you know,
you buy the ticket and,
151
00:07:47,133 --> 00:07:49,936
you know, you just win something.
152
00:07:49,936 --> 00:07:52,305
Once you select it,
153
00:07:52,305 --> 00:07:55,608
to produce that block,
whether it is Solana or Ethereum,
154
00:07:56,943 --> 00:08:00,413
there is a competition
over operational excellence.
155
00:08:00,880 --> 00:08:04,050
And the rewards
that you get really depends on that.
156
00:08:04,050 --> 00:08:07,854
In other words, you can actually change
the size of the lottery that you win
157
00:08:08,221 --> 00:08:10,890
by your operations and by your set up.
158
00:08:10,890 --> 00:08:13,893
So in the stadium, in that 12 seconds,
159
00:08:14,694 --> 00:08:19,632
you know, you basically propose a block
that has the highest value,
160
00:08:19,632 --> 00:08:22,635
but that block is given to you
by some builder, of course.
161
00:08:23,069 --> 00:08:26,472
But if you don't do it within that
12 second, that's a missed opportunity.
162
00:08:26,839 --> 00:08:32,445
In Solana, this is even more massive
because you have a fraction of that time
163
00:08:32,945 --> 00:08:35,948
and you're actually building the block
yourself.
164
00:08:36,148 --> 00:08:39,785
And so, your operations matter
a lot in terms of how much rewards
165
00:08:39,785 --> 00:08:41,287
you're going to get at the end of the day.
166
00:08:43,656 --> 00:08:44,423
Fantastic.
167
00:08:44,423 --> 00:08:45,825
Thank you for crystallizing that for us.
168
00:08:45,825 --> 00:08:51,130
You know, moving forward, you hear a lot
about validators, delegators and rewards.
169
00:08:51,130 --> 00:08:54,834
So, I'm hoping you can explain
the key components of staking.
170
00:08:56,736 --> 00:09:00,540
I think if I could start on that one,
I think, in my mind
171
00:09:00,573 --> 00:09:03,543
when we talk about staking, I think really
172
00:09:03,609 --> 00:09:06,112
one of the most important distinctions
in the two actors
173
00:09:06,112 --> 00:09:08,881
that are really important
are stakers and operators.
174
00:09:08,881 --> 00:09:11,551
And so, you know, you can say stakers,
175
00:09:11,551 --> 00:09:14,520
you can say delegators,
and you can say operators or validators.
176
00:09:14,820 --> 00:09:18,257
But I think the distinction
is essentially the token holder.
177
00:09:18,724 --> 00:09:21,427
And then the one actually
running the infrastructure, running
178
00:09:21,427 --> 00:09:24,430
the software that does those tasks
I mentioned earlier.
179
00:09:24,830 --> 00:09:29,001
And, you know, there are some networks
known as delegated proof of stake networks
180
00:09:29,001 --> 00:09:33,472
that are built around this concept,
recognizing that not every token holder,
181
00:09:33,472 --> 00:09:36,609
although they want to be involved
with staking and helping the network
182
00:09:36,609 --> 00:09:39,879
reach consensus, they don't actually,
necessarily, want to run the software.
183
00:09:40,212 --> 00:09:43,015
And so, networks like Solana that Reza
184
00:09:43,015 --> 00:09:46,018
mentioned, that's a good example
of a delegated proof of stake network.
185
00:09:46,018 --> 00:09:50,289
And if you go on and explore for Solana by
the way, you can often see the operator.
186
00:09:50,289 --> 00:09:51,424
You can see how much they have
187
00:09:51,424 --> 00:09:54,427
of their own token stake
and then how much has been delegated.
188
00:09:54,794 --> 00:09:55,861
Ethereum's a little different
189
00:09:55,861 --> 00:09:59,665
in the sense that it wasn't built
with this concept of delegation.
190
00:09:59,665 --> 00:10:04,770
So, anyone who wants to run a validator
or operate on Ethereum,
191
00:10:05,371 --> 00:10:08,040
they have to actually go ahead
and activate a validate.
192
00:10:08,040 --> 00:10:09,675
Every validator takes 32e.
193
00:10:11,010 --> 00:10:12,178
But even
194
00:10:12,178 --> 00:10:15,581
though Ethereum wasn't built
with this delegated proof of stake model,
195
00:10:16,082 --> 00:10:19,051
that is actually what's going on
in the background in a lot of cases,
196
00:10:19,051 --> 00:10:21,921
as I mentioned, you know,
Figment is a staking service provider.
197
00:10:21,921 --> 00:10:25,625
We do
run validators on Ethereum for customers.
198
00:10:26,225 --> 00:10:28,861
And there are other things too,
like liquid staking protocols
199
00:10:28,861 --> 00:10:30,930
that basically do
the same thing on Ethereum.
200
00:10:30,930 --> 00:10:34,300
So even though Ethereum doesn't
look like a delegated proof
201
00:10:34,300 --> 00:10:37,403
of stake system,
there is delegation happening
202
00:10:37,570 --> 00:10:40,573
kind of on the back
end of Ethereum as well.
203
00:10:41,240 --> 00:10:43,542
Again, I'm going
204
00:10:43,542 --> 00:10:46,545
to add to what Ben said and again,
205
00:10:47,246 --> 00:10:48,881
that this is basically some
206
00:10:48,881 --> 00:10:51,917
cleansing across
different proof of stake networks,
207
00:10:51,917 --> 00:10:57,256
which is baked in their protocol,
like in Solana and in Ethereum, it is not.
208
00:10:57,256 --> 00:10:57,990
And it
209
00:10:59,091 --> 00:11:02,094
sometimes is rooted in their ethos.
210
00:11:02,361 --> 00:11:05,131
Like for Ethereum,
211
00:11:05,131 --> 00:11:08,100
the idea of decentralization,
212
00:11:08,701 --> 00:11:10,569
happens like they want
213
00:11:10,569 --> 00:11:14,407
people to run these nodes
on consumer grade hardware.
214
00:11:15,441 --> 00:11:17,910
And because of that, you know,
215
00:11:17,910 --> 00:11:22,214
the whole idea was that start delegation,
you are going to take a more active role.
216
00:11:22,214 --> 00:11:25,217
That's the design versus in Solana,
217
00:11:25,685 --> 00:11:28,120
it's all about speed. It's about tuple.
218
00:11:28,120 --> 00:11:32,224
And you cannot run that
on a consumer grade hardware you need.
219
00:11:32,358 --> 00:11:35,361
So that's why they actually have the specs
for the type of hardware
220
00:11:35,461 --> 00:11:36,896
that you're going to run.
221
00:11:36,896 --> 00:11:39,298
And that's why
this distinction was very important.
222
00:11:39,298 --> 00:11:42,301
Not everybody could run that
and have that operation.
223
00:11:42,435 --> 00:11:48,507
So that that's why the delegation
is an important role.
224
00:11:48,507 --> 00:11:52,344
And one more thing that I want to mention
225
00:11:52,344 --> 00:11:56,716
is that the more actors in this space,
let's say in
226
00:11:56,716 --> 00:11:57,750
Ethereum than just delegated to Stakers,
we have, like builders and searchers
227
00:11:57,750 --> 00:12:03,856
that their job is actually,
building the block and the validate
228
00:12:03,856 --> 00:12:07,059
is basically outsourced to them
229
00:12:07,059 --> 00:12:10,262
when it comes to Ethereum.
230
00:12:11,731 --> 00:12:14,734
So they're
working with these different actors.
231
00:12:15,134 --> 00:12:20,406
Basically making strategic decisions
232
00:12:20,673 --> 00:12:25,277
on how to engage with them
is one part of our job as a node operator.
233
00:12:25,711 --> 00:12:26,345
Got it.
234
00:12:26,345 --> 00:12:29,482
Now, staking
does seem like an attractive proposition,
235
00:12:29,482 --> 00:12:32,852
but if I'm understanding it correctly,
it's not completely without its risks.
236
00:12:32,852 --> 00:12:36,622
So, can you give us an overview
of the risks involved in staking?
237
00:12:37,757 --> 00:12:39,091
Absolutely.
238
00:12:39,091 --> 00:12:41,794
So, I think I might kind of tee
this up generally
239
00:12:41,794 --> 00:12:44,797
and then I'll get into Ethereum
as a, as an example.
240
00:12:44,964 --> 00:12:49,535
So, I think it's important to understand
that there in my mind
241
00:12:49,535 --> 00:12:52,838
two broad categories, of penalties.
242
00:12:53,372 --> 00:12:55,775
One is implicit and the other is explicit.
243
00:12:55,775 --> 00:12:59,145
I think of implicit as I'm thinking
of opportunity cost.
So as an example
244
00:12:59,645 --> 00:13:01,180
on Ethereum,
245
00:13:01,180 --> 00:13:04,617
when you're selected to propose a block,
if you happen to miss that,
246
00:13:04,617 --> 00:13:05,985
in other words, you don't propose
247
00:13:05,985 --> 00:13:09,588
a block when you're assigned
to, there's no explicit penalty with that.
248
00:13:10,022 --> 00:13:11,824
The penalty is the opportunity cost.
249
00:13:11,824 --> 00:13:15,895
In other words, when you propose a block,
you get more rewards than you do
250
00:13:15,895 --> 00:13:19,532
for a testing, let's say, which is another
task
validators are required to do.
251
00:13:20,032 --> 00:13:23,636
So, the penalty there, in a sense, is
you don't have it
252
00:13:23,636 --> 00:13:27,072
taken away, but you really don't
want to be missing those blocks.
253
00:13:27,072 --> 00:13:29,775
That's kind of
what Reza alluded to earlier.
254
00:13:29,775 --> 00:13:30,976
So that's what I call implicit.
255
00:13:30,976 --> 00:13:34,747
However, there are also explicit penalties
where you actually do have
256
00:13:34,747 --> 00:13:36,549
some of your tokens taken away.
257
00:13:36,549 --> 00:13:37,850
And as I mentioned at the outset,
you know,
258
00:13:37,850 --> 00:13:40,853
when I kind of framed things
as there’s this agreement
259
00:13:41,053 --> 00:13:43,923
between the token holder
when they’re taking on the protocol,
260
00:13:43,923 --> 00:13:47,593
if you fail to do certain duties,
you can have tokens taken away.
261
00:13:48,227 --> 00:13:51,230
To make this a little more concrete,
I try and keep this short,
262
00:13:51,297 --> 00:13:54,633
but let’s talk real quick about the risks
and penalties on Ethereum.
263
00:13:55,000 --> 00:13:59,738
And I'll go in order of,
just the magnitude of these risks.
264
00:14:00,306 --> 00:14:00,973
So first,
265
00:14:00,973 --> 00:14:05,010
the lowest kind of risk that you can face
are what I call performance penalties,
266
00:14:05,344 --> 00:14:08,347
some people also refer to them
as downtime penalties.
267
00:14:08,881 --> 00:14:12,818
So, one of the things you have to do
as a validator on Ethereum is a test.
268
00:14:12,952 --> 00:14:15,454
And a test
just basically means as a validator,
269
00:14:15,454 --> 00:14:17,923
this is what Ethereum state
looks like to me. Okay.
270
00:14:17,923 --> 00:14:21,727
And you actually report on three different
items when you make that attestation.
271
00:14:23,162 --> 00:14:25,064
Two of these items, if you
272
00:14:25,064 --> 00:14:28,667
don't respond in a timely way
or in a correct way, carry a penalty.
273
00:14:29,335 --> 00:14:31,170
Okay. And this is where downtime
penalties comes in.
274
00:14:31,170 --> 00:14:34,740
If you're a validator, let's say
is totally offline, you're going to start
275
00:14:34,740 --> 00:14:37,743
to accrue these penalties.
Again,
just to put this in context,
276
00:14:38,277 --> 00:14:42,681
validators on Ethereum are asked to attest
225 times per day.
277
00:14:43,215 --> 00:14:45,784
So, at roughly around 6.4 minutes, you're
278
00:14:45,784 --> 00:14:48,787
expected to attest, okay.
279
00:14:49,221 --> 00:14:51,724
On the other side
though in terms of rewards
280
00:14:51,724 --> 00:14:54,560
for these three duties
you do, you will gain rewards
281
00:14:54,560 --> 00:14:57,663
if you do them again in a timely manner
and in a correct manner.
282
00:14:58,130 --> 00:15:00,799
So just to note,
there's a bit of an asymmetry here.
283
00:15:00,799 --> 00:15:04,036
If you were offline,
let's say for an hour to gain back
284
00:15:04,303 --> 00:15:08,073
the rewards that you've lost,
you would have to be online
285
00:15:08,073 --> 00:15:10,409
for slightly less than an hour
because there's asymmetry.
286
00:15:10,409 --> 00:15:12,378
Anyway, that's a bit of a nuance.
287
00:15:12,378 --> 00:15:16,048
And just again, to put this into context,
if you're offline for an hour,
288
00:15:16,048 --> 00:15:19,718
the cost in dollars is around 15 to $0.20.
289
00:15:20,185 --> 00:15:23,188
So, we're talking
not massive penalties, okay.
290
00:15:23,822 --> 00:15:27,259
The next set of penalties
is referred to as inactivity.
291
00:15:28,227 --> 00:15:29,695
Now this is a special
292
00:15:29,695 --> 00:15:32,698
situation, a little bit complicated,
so just bear with me.
293
00:15:32,865 --> 00:15:35,868
There's this concept of finalization
on Ethereum.
294
00:15:36,035 --> 00:15:40,773
The idea with finalization
is that once a block becomes finalized
295
00:15:41,407 --> 00:15:46,612
and technically you actually finalize
per epoch, there are 32 slots in an epoch.
296
00:15:46,712 --> 00:15:49,682
Typically,
there are 32 blocks in an epoch.
297
00:15:50,416 --> 00:15:53,852
That full epoch will become finalized
at the same time.
298
00:15:53,852 --> 00:15:57,456
So, in other words, Ethereum moves
in this kind of cadence of 32
299
00:15:57,756 --> 00:16:00,693
slots at a time, or roughly 32 blocks.
300
00:16:00,693 --> 00:16:03,696
But once a block itself
has become finalized,
301
00:16:04,730 --> 00:16:08,033
the likelihood that it becomes reverted,
in other words, history
302
00:16:08,033 --> 00:16:11,670
kind of undoes itself is very, very low.
Now, there are more nuances here,
303
00:16:11,670 --> 00:16:14,239
and it has to do with Ethereum's
consensus mechanism.
304
00:16:14,239 --> 00:16:15,341
I'm going to push that aside for now.
305
00:16:15,341 --> 00:16:17,943
We can get into it later,
but we really get into the weeds
306
00:16:17,943 --> 00:16:19,545
and nitty gritty of Ethereum
if we go there.
307
00:16:19,545 --> 00:16:22,114
So, I'm just going to going
to leave it aside for now.
308
00:16:22,114 --> 00:16:22,915
But the point is,
309
00:16:23,882 --> 00:16:25,884
Ethereum expects to finalize
310
00:16:25,884 --> 00:16:30,089
roughly every 13 minutes.
But if there's a period
311
00:16:30,689 --> 00:16:34,560
of more than four epochs
in which Ethereum has not finalized.
312
00:16:34,560 --> 00:16:38,030
So, if you enter the fifth epoch
and Ethereum is not finalized,
313
00:16:38,430 --> 00:16:40,432
you enter inactivity.
314
00:16:40,432 --> 00:16:44,970
And what happens with inactivity
is that non-performing validators,
315
00:16:44,970 --> 00:16:46,171
in addition to the penalties,
316
00:16:46,171 --> 00:16:49,141
I just talked about performance penalties
or downtime penalties.
317
00:16:49,575 --> 00:16:52,578
There's an additional penalty
called inactivity leak.
318
00:16:53,479 --> 00:16:57,216
And this penalty, the way it looks
is it starts off small, similar
319
00:16:57,216 --> 00:17:01,820
in magnitude to the performance penalties,
but it increases very quickly, okay.
320
00:17:01,820 --> 00:17:04,923
So, to give a sense,
if you had a day in inactivity leak,
321
00:17:05,524 --> 00:17:07,459
your Ethereum balance
at the end of that day,
322
00:17:07,459 --> 00:17:11,764
if you're a non-performing validator
would be about 99.9% of your balance.
323
00:17:12,197 --> 00:17:15,601
Okay, so not really a huge difference,
but 0.1% under the statement.
324
00:17:16,902 --> 00:17:19,938
After a week that number is about 93%.
325
00:17:19,938 --> 00:17:22,207
So now 7% of it is taken.
326
00:17:22,207 --> 00:17:25,411
After two weeks, we're at about 74%.
327
00:17:25,778 --> 00:17:28,547
And after three weeks about half of it
is taken away.
328
00:17:28,547 --> 00:17:31,784
So, what I'm trying to get across
is it starts very low,
329
00:17:32,184 --> 00:17:35,187
but it ratches up very quickly.
330
00:17:35,320 --> 00:17:38,323
Just bear with me
almost through the risks here on Ethereum,
331
00:17:38,323 --> 00:17:41,326
I just want to mention two more things.
First,
332
00:17:41,460 --> 00:17:44,930
the goal of inactivity leak
and kind of give some context around this.
333
00:17:44,930 --> 00:17:47,232
The idea is
334
00:17:47,232 --> 00:17:48,901
Ethereum not finalizing is
335
00:17:48,901 --> 00:17:51,904
an abnormal situation
and it's not a healthy one.
336
00:17:51,937 --> 00:17:56,041
Ethereum needs to get back to finalizing
because it's finalizing is important
337
00:17:56,041 --> 00:17:57,076
for all kinds of reasons.
338
00:17:57,076 --> 00:18:00,345
One of the big ones is for the user’s
sake.
339
00:18:00,345 --> 00:18:04,149
So, the idea with inactivity leak is what
we need to do.
We being Ethereum,
340
00:18:04,516 --> 00:18:08,787
is to weed out the non-performing
validators, reduce their balance
341
00:18:09,121 --> 00:18:12,124
to such a point
that we can get back to finalization.
342
00:18:12,758 --> 00:18:14,159
And as a reminder, on Ethereum,
343
00:18:14,159 --> 00:18:16,929
finalization
takes two thirds of validators.
344
00:18:16,929 --> 00:18:18,197
So what? What happens is
345
00:18:19,198 --> 00:18:22,201
validators that are performing
during inactivity leak,
346
00:18:22,301 --> 00:18:24,303
their balance stays the same
even if they're performing
347
00:18:24,303 --> 00:18:26,071
so they don't actually get rewards.
The penalties
348
00:18:26,071 --> 00:18:29,041
and rewards offset each other,
but their balance stays the same.
349
00:18:29,341 --> 00:18:32,344
Non-performing
validators have the performance penalties,
350
00:18:32,344 --> 00:18:36,615
but they also get inactivity leak,
so their relative difference increases.
351
00:18:36,949 --> 00:18:40,352
Performance validators
now represent more and more voting weight
352
00:18:40,352 --> 00:18:44,123
on Ethereum, and non-performing validators
represent less and less.
353
00:18:44,123 --> 00:18:47,126
The idea is if we can drain away
354
00:18:47,359 --> 00:18:50,028
the non-performing validators, eventually
355
00:18:50,028 --> 00:18:53,031
we will get back to finalization
and that's the goal of an activity
356
00:18:53,999 --> 00:18:58,203
I would say is somewhere
between non-performance risk or penalties
357
00:18:58,637 --> 00:19:02,441
and then slashing penalties.
I would say
that slashing penalties, don't worry.
358
00:19:02,441 --> 00:19:06,879
The last risk that I want to address
359
00:19:08,580 --> 00:19:10,616
has the potential to be the most severe.
360
00:19:11,950 --> 00:19:14,253
So slashing, real quick.
361
00:19:14,253 --> 00:19:16,021
And this is similar across most networks.
362
00:19:16,021 --> 00:19:18,657
The idea is equivocation
or double signing.
363
00:19:18,657 --> 00:19:21,727
In other words, as a validator,
what you're doing is basically
364
00:19:23,061 --> 00:19:25,831
attesting
or saying that there are two states
365
00:19:25,831 --> 00:19:28,800
of reality or more at the same time.
And that's a problem.
366
00:19:29,268 --> 00:19:29,768
You can't do that.
367
00:19:29,768 --> 00:19:32,738
It's kind of like, if you think for
an analogy here, kind of like perjury.
368
00:19:32,738 --> 00:19:35,541
If you're testifying in court
or something, you're kind of saying
369
00:19:35,541 --> 00:19:38,544
that there are two different realities
and that can't be the case.
370
00:19:39,011 --> 00:19:42,748
So, on Ethereum, it's the same thing
if you proposed in a way.
So,
371
00:19:42,748 --> 00:19:45,884
if you proposed two different blocks at
the same time, that's a slashable offence.
372
00:19:46,285 --> 00:19:49,655
Or if you attest, in other words,
say here's my view of Ethereum,
373
00:19:49,988 --> 00:19:52,658
but you say they're
two different realities at the same time.
374
00:19:52,658 --> 00:19:55,561
That's a slashable offence.
If you commit a slashable,
375
00:19:56,728 --> 00:19:59,131
the result is the same.
376
00:19:59,131 --> 00:20:00,566
There's an initial penalty.
377
00:20:00,566 --> 00:20:04,236
Today it's 130 seconds of your balance.
So, if you're holding 32e
378
00:20:04,236 --> 00:20:07,239
that's typically the case, you lose 1e.
379
00:20:07,539 --> 00:20:09,942
After that, there's a 36-day period
380
00:20:09,942 --> 00:20:12,945
where you accrue or sorry, incur
381
00:20:13,345 --> 00:20:17,282
these performance penalties, okay.
382
00:20:17,282 --> 00:20:18,984
So, like the one I first mentioned.
383
00:20:18,984 --> 00:20:21,987
In other words,
you're not contributing to,
384
00:20:22,020 --> 00:20:23,822
you're not properly attesting
385
00:20:23,822 --> 00:20:27,993
to Ethereum for 36 days.
Now, here's
a little bit of a complicated part.
386
00:20:27,993 --> 00:20:29,561
The last thing that happens.
387
00:20:29,561 --> 00:20:32,564
And by the way, while this is happening,
you're being exited from the active set.
388
00:20:32,965 --> 00:20:35,968
You're also being booted out the exit.
389
00:20:36,001 --> 00:20:39,071
18 days into that 36 day period,
390
00:20:39,071 --> 00:20:42,441
a proportional slashing multiplier
like this is the dangerous bit.
391
00:20:43,709 --> 00:20:46,445
What happens is Ethereum says
392
00:20:46,445 --> 00:20:49,548
in kind of a colloquial or what
would you say,
393
00:20:49,581 --> 00:20:51,750
kind of like an analogy here.
This obviously isn't literally
394
00:20:51,750 --> 00:20:54,152
what happens, but Ethereum says to itself,
are we being attacked?
395
00:20:55,120 --> 00:20:58,023
And the way that Ethereum assesses
that is, it looks at the proportion
396
00:20:58,023 --> 00:21:01,994
of other validators that have also
committed a slashable offence.
397
00:21:01,994 --> 00:21:06,298
So, let's say 18 days into your 36-day
window, Ethereum
398
00:21:06,298 --> 00:21:10,802
looks 18 days before you committed
your slashable offence, 18 days after.
399
00:21:11,069 --> 00:21:14,072
And it calculates
the percentage based on the state of
400
00:21:14,573 --> 00:21:17,342
other validators
that have committed a slashable offense.
401
00:21:17,342 --> 00:21:20,879
It takes the percentage, let's say it's 5%
and it multiplies it by three.
402
00:21:21,146 --> 00:21:22,481
So, you get 15%.
403
00:21:22,481 --> 00:21:24,983
That's the additional amount of tokens
that are taken away from you
404
00:21:24,983 --> 00:21:25,884
with slashing.
405
00:21:25,884 --> 00:21:27,853
That's the proportional
slashing multiplier.
406
00:21:27,853 --> 00:21:30,622
I know it's a lot,
but this is convoluted.
So
407
00:21:30,622 --> 00:21:34,726
those are the three broad risks
in running a validator.
408
00:21:35,794 --> 00:21:38,263
Obviously, different networks
look different.
409
00:21:38,263 --> 00:21:40,098
Some of them are less punitive.
410
00:21:40,098 --> 00:21:43,702
So, for instance,
I talked about implicit versus explicit.
411
00:21:43,969 --> 00:21:46,071
Some networks don't penalize you.
412
00:21:46,071 --> 00:21:49,174
What they do is jail you, meaning they
take your validator out of the active set.
413
00:21:49,741 --> 00:21:52,377
They make you sit in the penalty box
for a while, and then you can get back in
414
00:21:52,377 --> 00:21:55,714
and start validating again.
There's that opportunity cost
415
00:21:56,114 --> 00:21:59,284
or implicit penalty of being taken out
and not earning rewards.
416
00:21:59,785 --> 00:22:01,320
Anyway,
I'll take a pause. That's a lot. So,
417
00:22:02,354 --> 00:22:04,589
and Ben just to
418
00:22:04,589 --> 00:22:09,394
piggyback off that, how is it
fair to say that slashing events on
419
00:22:09,394 --> 00:22:13,365
Ethereum, at least,
are quite infrequent or uncommon?
420
00:22:13,765 --> 00:22:16,768
How many slashing events typically happen
421
00:22:16,768 --> 00:22:19,771
in a year on Ethereum?
422
00:22:19,905 --> 00:22:23,442
Well, what I can tell you,
I don't have the number like per year,
423
00:22:23,442 --> 00:22:26,445
but I would say, well, roughly,
you know, Beacon Chain has been around
424
00:22:26,611 --> 00:22:29,581
for roughly four years,
launched end of 2020.
425
00:22:29,981 --> 00:22:32,918
I think there's something I have to check,
but it's probably the magnitude
426
00:22:32,918 --> 00:22:35,921
is around 400 slashable offenses.
427
00:22:35,954 --> 00:22:38,590
So, you know, you do
the math, let's say roughly 100 a year
428
00:22:38,590 --> 00:22:41,259
probably skewed
towards the launch of Beacon Chain.
429
00:22:41,259 --> 00:22:45,163
People are figuring things out,
but I take that as a rough guide.
430
00:22:45,163 --> 00:22:46,998
So, to answer your question, George,
431
00:22:48,033 --> 00:22:50,736
not hugely frequent.
432
00:22:50,736 --> 00:22:52,938
I think we'll get into this
maybe more a little bit later.
433
00:22:52,938 --> 00:22:54,873
But I would say that
Ethereum is constantly changing.
434
00:22:54,873 --> 00:22:55,440
And to your point,
435
00:22:55,440 --> 00:22:59,611
which is a great one, you know, Ethereum
as we understand it today, i.e.
436
00:22:59,611 --> 00:23:03,949
post-merge Ethereum has only been around
for two years.
So,
437
00:23:04,683 --> 00:23:07,919
we can set our empirical, expectations
or whatever.
438
00:23:08,286 --> 00:23:10,088
But Ethereum's a changing animal.
439
00:23:10,088 --> 00:23:13,592
So, I kind of just want to highlight
that point I think that was
440
00:23:13,592 --> 00:23:17,229
a great synopsis of the technical risks
associated with staking.
441
00:23:17,562 --> 00:23:20,565
But just to add
one more on the non-technical side,
442
00:23:20,899 --> 00:23:24,102
and that is regulatory uncertainty
as it relates to staking.
443
00:23:24,102 --> 00:23:29,307
So, as it stands today, there's
a bit of an inconsistent global approach
444
00:23:29,307 --> 00:23:33,211
as to how to regulate staking.
So different countries and jurisdictions
445
00:23:33,211 --> 00:23:36,715
are taking varied approaches
to regulating the space.
446
00:23:37,249 --> 00:23:40,519
That creates some challenges for companies
operating across borders
447
00:23:40,952 --> 00:23:44,389
and for investors participating in global
staking pools, right.
448
00:23:45,090 --> 00:23:49,327
There's also an ongoing debate
about whether staking rewards should be
449
00:23:49,327 --> 00:23:53,532
classified as income, capital gains,
or something else entirely.
450
00:23:54,099 --> 00:23:58,236
So, data ambiguity
also affects tax reporting and compliance.
451
00:23:58,970 --> 00:24:02,674
But ultimately, the rapid pace of change
452
00:24:02,674 --> 00:24:06,578
and innovation in crypto usually outpaces
regulatory developments.
So,
453
00:24:06,978 --> 00:24:11,283
this is something that regulators are now
educating themselves on
454
00:24:11,283 --> 00:24:16,254
and introducing new guidelines
for all participants involved in staking.
455
00:24:16,254 --> 00:24:16,588
Yeah.
456
00:24:18,990 --> 00:24:21,426
Ben thanks for that.
457
00:24:21,426 --> 00:24:22,561
You know, great explanation
458
00:24:22,561 --> 00:24:25,564
on all the different technical risks
that relate to staking.
459
00:24:26,765 --> 00:24:29,401
The way I see it is
460
00:24:29,401 --> 00:24:33,772
there are certainly some unique risks
associated with staking, like you
461
00:24:33,772 --> 00:24:38,410
mentioned, slashing,
making sure that, you know, the validators
462
00:24:39,311 --> 00:24:43,715
are in conformance with Ethereum
requirements, the protocol requirements,
463
00:24:44,382 --> 00:24:49,588
so that they always remain on
the most recent canonical chain.
Right.
464
00:24:49,588 --> 00:24:53,925
So that is, absolutely,
you know, a risk to consider.
465
00:24:53,925 --> 00:24:57,596
But a lot of the other risks
that you mentioned around being available,
466
00:24:57,596 --> 00:25:00,599
you know, being, the uptime
that is expected,
467
00:25:00,899 --> 00:25:03,401
those risks are not new.
468
00:25:03,401 --> 00:25:07,105
Those risks are traditional risks
that have existed,
469
00:25:07,105 --> 00:25:10,408
you know, around data centers
and other businesses
470
00:25:10,976 --> 00:25:14,880
and the way when I put on my technology
risk hat.
471
00:25:14,880 --> 00:25:18,750
I've been a technology risk auditor
all my life, when I put on that hat,
472
00:25:19,417 --> 00:25:20,151
these risks have
473
00:25:21,453 --> 00:25:23,655
also traditional ways of
474
00:25:23,655 --> 00:25:26,892
being addressed.
So having a, you know,
business continuity plan in place,
475
00:25:26,892 --> 00:25:30,962
a disaster recovery plan in place,
making sure your infrastructure
476
00:25:32,130 --> 00:25:36,034
is adequate enough
to, you know, let's say,
477
00:25:36,501 --> 00:25:39,304
be able to meet those commitments
478
00:25:39,304 --> 00:25:44,142
of uptime, availability, etc.,
that obviously,
479
00:25:44,376 --> 00:25:47,379
you know, are some of the things
to consider and think about.
480
00:25:47,913 --> 00:25:49,614
But beyond that,
481
00:25:49,614 --> 00:25:52,851
there are also some risks related
to, let's say,
482
00:25:53,151 --> 00:25:56,321
more on the crypto side of it
The key
483
00:25:56,321 --> 00:25:59,324
management, the smart contract, right,
484
00:25:59,758 --> 00:26:02,761
so can you highlight a little bit more on
485
00:26:03,361 --> 00:26:07,365
how relevant those risks are and how are
some of those risks are different
486
00:26:07,365 --> 00:26:11,836
from your existing risks
in the crypto space?
487
00:26:11,836 --> 00:26:13,471
That's great.
488
00:26:13,471 --> 00:26:17,542
You know, and I really like the point too
about just going back for a second,
489
00:26:17,876 --> 00:26:21,780
you know,
there are well known methods to address
490
00:26:21,780 --> 00:26:25,550
some of the risks, like uptime and things
like that.
And, I'm glad you mentioned
491
00:26:25,550 --> 00:26:28,620
key security, because that's something
I think that's often overlooked.
492
00:26:28,653 --> 00:26:30,956
And I think staking is an interesting one.
493
00:26:30,956 --> 00:26:33,458
So, you know,
we're all aware of key security risks.
494
00:26:33,458 --> 00:26:34,259
You hear about,
495
00:26:34,259 --> 00:26:37,829
you know, my key was compromised because
I use a bad app or something like that.
496
00:26:37,829 --> 00:26:39,731
And this is now,
I'm not talking so much about validators.
497
00:26:39,731 --> 00:26:40,832
I'm talking about users.
498
00:26:42,133 --> 00:26:45,136
And staking is kind of interesting
because,
499
00:26:45,837 --> 00:26:48,840
you know, tying back to some of the risks
that I talked about, slashing.
500
00:26:49,441 --> 00:26:52,944
There is a risk of slashing
if you have a compromised validator key
501
00:26:53,945 --> 00:26:58,183
and there's also a risk in terms
of just mismanagement of a backup process.
502
00:26:58,183 --> 00:27:01,186
And I'll come back to that in a second.
But what's interesting is that
503
00:27:02,020 --> 00:27:05,223
with a validator, at least on Ethereum,
and I think a lot of other networks
504
00:27:05,724 --> 00:27:08,026
potentially similar,
505
00:27:08,026 --> 00:27:11,630
it's a different kind of risk if you have
your validator key compromised.
506
00:27:11,796 --> 00:27:15,100
And so, you know, you think about it,
it's like if you were trying
507
00:27:15,100 --> 00:27:18,103
to steal someone's Eth, let's say
508
00:27:18,470 --> 00:27:22,507
stealing from a validator is probably
the last thing you would try to do,
509
00:27:22,741 --> 00:27:25,810
because it's a lot easier to steal,
presumably from someone's EOA
510
00:27:26,011 --> 00:27:29,481
instead of some sort of sketchy.
I don't
know, Efi app or something like that.
511
00:27:29,681 --> 00:27:32,784
And then you have, private signature
and then you can do whatever you want,
512
00:27:33,051 --> 00:27:36,121
whereas, you know, not to say
it will never happen,
513
00:27:36,621 --> 00:27:40,392
but the Eth going from Beacon Chain to,
514
00:27:41,226 --> 00:27:44,195
an EOA externally owned account,
other than
515
00:27:44,195 --> 00:27:47,198
what is specified in the withdrawal
credentials, has never happened,
516
00:27:47,298 --> 00:27:50,268
and I don't suspect it
to.
So, it's kind of interesting.
517
00:27:50,268 --> 00:27:54,406
This key security is still very important,
but the risk is a little bit
518
00:27:54,406 --> 00:27:57,409
different than when you think of
e-security as a user.
519
00:27:57,442 --> 00:28:00,712
The other thing too, I wanted to mention
in terms of backup strategies,
520
00:28:01,012 --> 00:28:04,582
I think I absolutely agree
that there are known solutions
521
00:28:04,582 --> 00:28:07,585
to some of these problems.
The one thing
I would say, though, and just caution,
522
00:28:07,652 --> 00:28:10,689
if you're thinking about maximizing
uptime,
523
00:28:11,523 --> 00:28:15,894
is, you know, some of these slashings
that we've seen
524
00:28:16,428 --> 00:28:19,197
have been related to, operators,
525
00:28:19,197 --> 00:28:22,233
backup systems and the idea is that,
526
00:28:22,600 --> 00:28:25,270
you know, if you have a primary,
let's say you're worried about
527
00:28:26,671 --> 00:28:29,140
your cloud provider going down.
Okay.
528
00:28:29,140 --> 00:28:30,408
And so, you've got, let's say,
529
00:28:30,408 --> 00:28:33,845
I don't know, ABC cloud provider
and then XYZ cloud provider.
530
00:28:33,845 --> 00:28:37,482
And you run your primary on ABC
and you run your backup on XYZ.
531
00:28:38,583 --> 00:28:41,853
What you don't want to happen
is to have those validator keys
532
00:28:41,853 --> 00:28:45,390
running on both clouds at the same time,
because now you're going to commit
533
00:28:45,824 --> 00:28:46,458
a slashable offence.
534
00:28:46,458 --> 00:28:51,596
And so, I think I absolutely agree and all
and I think that, looking at Web2 and,
535
00:28:51,596 --> 00:28:55,400
and some other areas of the tech space
are very informative and important.
536
00:28:55,800 --> 00:28:59,804
But I think that there's this, this layer
of nuance with, with crypto and Web3,
537
00:29:00,338 --> 00:29:03,374
that I think that folks
should just generally be mindful
538
00:29:03,408 --> 00:29:05,643
of in
terms
of risk management and optimizing uptime.
539
00:29:08,446 --> 00:29:11,216
I want to add to that,
540
00:29:11,216 --> 00:29:12,984
you know, at Figment
541
00:29:12,984 --> 00:29:15,987
we have this mantra,
safety over lightness,
542
00:29:16,020 --> 00:29:20,024
and that's actually rooted in exactly
what Ben has been describing.
543
00:29:20,692 --> 00:29:23,328
Earlier
he mentioned that the penalties for
544
00:29:23,328 --> 00:29:28,800
being offline is just like a few bucks,
545
00:29:30,068 --> 00:29:32,937
even if you are off for a whole day,
right.
546
00:29:32,937 --> 00:29:35,406
I'm ignoring, the inactivity leaks
547
00:29:35,406 --> 00:29:38,409
and those kind of situations.
548
00:29:38,443 --> 00:29:40,845
But, so when,
549
00:29:40,845 --> 00:29:43,848
let's say the cloud provider is off,
550
00:29:43,982 --> 00:29:49,454
some might be tempted to go
with having a backup system
551
00:29:49,454 --> 00:29:54,425
that immediately starts your operations
in a different cloud or a different region
552
00:29:55,393 --> 00:29:58,897
to ensure
that the operation is continuing.
But
553
00:30:00,131 --> 00:30:04,402
in a risk adjusted reward type of model
554
00:30:04,936 --> 00:30:09,507
that doesn't justify that,
because the moment that you start doing
555
00:30:09,507 --> 00:30:13,144
double signing,
you will commit a slashable offense.
556
00:30:13,878 --> 00:30:18,149
And so what we do at Figment,
and we really encourage our customers
557
00:30:18,483 --> 00:30:22,253
to think this way is
that it's much better to stay offline
558
00:30:22,720 --> 00:30:26,391
and do not engage in
trying to optimize for uptime,
559
00:30:26,724 --> 00:30:30,628
which is, quite frankly,
usually around 99% or something,
right.
560
00:30:30,695 --> 00:30:34,732
Anyway, so for that extra 1%,
which translates to just a few bucks,
561
00:30:35,033 --> 00:30:38,169
don't try to risk, your full
562
00:30:38,736 --> 00:30:42,040
per validator and commit
a slashable offense.
563
00:30:42,240 --> 00:30:46,411
So, what we do is that we basically
stay offline, we don't do that.
564
00:30:46,978 --> 00:30:51,683
And this is interesting
because sometimes we want to ask that.
565
00:30:51,683 --> 00:30:56,321
Okay, you are offering your solutions
in different regions.
566
00:30:57,121 --> 00:31:01,159
And so,
it is completely feasible for us to do it.
567
00:31:01,159 --> 00:31:03,561
It’s just not logical.
568
00:31:03,561 --> 00:31:05,997
It’s not a risk adjusted
569
00:31:08,366 --> 00:31:11,035
reward in our definition.
570
00:31:11,035 --> 00:31:14,639
And I want to get back to what George says
about regulatory risks.
571
00:31:14,639 --> 00:31:18,076
On one of the things that,
572
00:31:18,810 --> 00:31:22,780
you know,
we take the risks and mitigation of risks
573
00:31:22,780 --> 00:31:26,851
very seriously and that kind of informs
our product strategy
574
00:31:28,019 --> 00:31:30,288
and the way that we approach things.
575
00:31:30,288 --> 00:31:34,893
And one of the tools in our toolkit
is the diversity.
576
00:31:35,493 --> 00:31:38,463
And, for something like regulatory risk,
577
00:31:39,097 --> 00:31:43,301
what we have done with that is
we offered the option to our customers
578
00:31:43,568 --> 00:31:46,571
to have their operations
in their region of choice,
579
00:31:47,138 --> 00:31:50,308
and it is also possible to migrate
from one region to another.
580
00:31:51,042 --> 00:31:54,279
So, this is basically, one of the ways
581
00:31:54,279 --> 00:31:57,282
that we allow our customers
582
00:31:58,049 --> 00:32:01,286
to strategize and to be strategic about
583
00:32:02,353 --> 00:32:05,523
the choices,
so they can mitigate risk.
And that one
584
00:32:05,523 --> 00:32:09,494
was related to regulatory and compliance.
585
00:32:09,494 --> 00:32:11,195
Fantastic advice.
586
00:32:11,195 --> 00:32:15,199
Now, given the risks that you mentioned,
what strategies can stakeholders employ
587
00:32:15,199 --> 00:32:16,034
to minimize?
588
00:32:17,201 --> 00:32:17,602
Great.
589
00:32:17,602 --> 00:32:18,536
Great question.
590
00:32:18,536 --> 00:32:21,539
I think just to start,
I do want to say, and this is going to be
591
00:32:21,572 --> 00:32:23,207
maybe a little bit obvious,
a little bit banal.
592
00:32:23,207 --> 00:32:26,577
So, but I do think understanding
593
00:32:27,278 --> 00:32:30,281
is the prerequisite
for proper risk management.
So,
594
00:32:31,716 --> 00:32:33,785
and again, it does sound kind of obvious,
595
00:32:33,785 --> 00:32:36,788
but I think to some folks, you know,
596
00:32:37,188 --> 00:32:39,724
at least with respect to Ethereum,
it's easy
597
00:32:39,724 --> 00:32:41,526
to think all Ethereum's
been around for a long time.
598
00:32:41,526 --> 00:32:42,560
And like the Ethereum
599
00:32:42,560 --> 00:32:44,729
we know today is the exact same
as when Beacon Chain launched.
600
00:32:44,729 --> 00:32:46,230
That's simply not the case.
601
00:32:46,230 --> 00:32:50,802
You know, again, to just kind of double
down on George's point.
We know today,
602
00:32:51,336 --> 00:32:54,539
you could argue
more or less happened September 2022.
603
00:32:54,839 --> 00:32:56,574
And there have been other forks
since then.
604
00:32:56,574 --> 00:32:59,577
So, the way I think about
it is a bit of a conceptual shift where,
605
00:33:00,211 --> 00:33:03,281
looking from today and going backwards,
the question is how far back
606
00:33:03,281 --> 00:33:06,284
you go before
Ethereum is so fundamentally changed
607
00:33:06,417 --> 00:33:09,420
that the logic is different.
You have to change the way you look at it.
608
00:33:09,721 --> 00:33:13,558
So, getting back on track and questions
about risk management, you know, Reza
609
00:33:13,558 --> 00:33:18,663
talked about the philosophy around
how do you think about earning rewards
610
00:33:18,963 --> 00:33:22,000
and not taking excessive risk
and putting your stake at excessive risk?
611
00:33:22,000 --> 00:33:24,802
I think philosophy
is one of the key things.
612
00:33:24,802 --> 00:33:28,039
If you're a token holder and you're
looking for a staking service provider,
613
00:33:28,406 --> 00:33:32,677
make sure that whichever
staking service provider you use aligns
614
00:33:32,677 --> 00:33:36,447
with your philosophy of risk,
and obviously everyone's risk preferences
615
00:33:36,447 --> 00:33:39,450
will change, will differ.
And you know, people can vary
616
00:33:39,450 --> 00:33:42,420
quite a bit in terms of their appetite
and willingness to accept risk.
617
00:33:42,820 --> 00:33:45,690
But I think philosophy is the first one
that needs to align.
618
00:33:45,690 --> 00:33:47,959
There are also technical
solutions too like there are
619
00:33:49,560 --> 00:33:51,896
programs
that help with slashing protection.
620
00:33:51,896 --> 00:33:55,600
So, if you look at the specs on Ethereum,
you can actually go to the lines
621
00:33:55,600 --> 00:33:58,770
of the specs.
And it's like between 10 to 15 lines that
622
00:33:59,170 --> 00:34:01,773
define what is a slash condition.
623
00:34:01,773 --> 00:34:05,209
So, you know, there are these programs
that are relatively simple.
624
00:34:05,209 --> 00:34:09,147
And basically, it amounts to a database
of what you signed as a validator.
625
00:34:09,414 --> 00:34:10,982
And it can check for you to make sure
626
00:34:10,982 --> 00:34:12,817
that you're
not going to commit a slashable offence.
627
00:34:12,817 --> 00:34:16,320
So that's one thing
that's a technical solution.
628
00:34:16,921 --> 00:34:19,390
But also,
you know, policies and procedures
629
00:34:19,390 --> 00:34:22,827
that kind of dovetail in your philosophy
are also very important.
630
00:34:22,827 --> 00:34:25,830
I think for me,
631
00:34:26,431 --> 00:34:29,067
I don't know if it's necessarily
policy or procedure, but
632
00:34:29,067 --> 00:34:32,103
I guess, the takeaway from the philosophy
is what you don't want to do.
633
00:34:32,103 --> 00:34:36,474
And Reza touched on this.
You don't
if there's a situation on Ethereum
634
00:34:36,474 --> 00:34:39,911
that's abnormal and you know, there's
an activity leak or something's
635
00:34:39,911 --> 00:34:42,914
happening, you don't understand
that the performance is degrading.
636
00:34:43,114 --> 00:34:45,983
What you don't want to do
is a knee jerk reaction to something.
637
00:34:45,983 --> 00:34:50,221
And, you know, migrate validators
or do something drastic
638
00:34:50,822 --> 00:34:55,460
to react and to try and maintain uptime.
It's better to take the loss for, however
639
00:34:55,460 --> 00:34:58,863
many hours, figure out what's going on,
and then react accordingly.
640
00:34:58,863 --> 00:35:03,768
And all of this is based on having a sound
understanding of how the network works.
641
00:35:04,235 --> 00:35:08,639
Okay, so you think about what are the
different ways in which I can be slashed.
642
00:35:09,073 --> 00:35:10,708
Okay. That's the most important thing.
643
00:35:12,076 --> 00:35:14,212
Customer
state is of paramount importance.
644
00:35:14,212 --> 00:35:17,815
And then everything else, you can kind of
prioritize according to that.
645
00:35:22,587 --> 00:35:24,422
I want to add to
646
00:35:24,422 --> 00:35:27,458
what Ben says and, regarding,
647
00:35:28,059 --> 00:35:32,930
some of the penalties
and some of the risks that people take is
648
00:35:33,131 --> 00:35:36,901
based on the, you know,
definitions of the protocol itself.
649
00:35:36,901 --> 00:35:42,273
It differs widely from one,
POS network to another.
650
00:35:42,840 --> 00:35:46,511
And, but there are also some, risks
651
00:35:46,511 --> 00:35:49,514
that are more subtle, but they can
652
00:35:51,082 --> 00:35:52,783
be very important.
653
00:35:52,783 --> 00:35:56,721
And again, understanding the risks as Ben
said is the key here.
654
00:35:57,155 --> 00:36:02,326
And one of the things that, you know,
for instance, we really think in
655
00:36:02,326 --> 00:36:05,329
our research is just that, reward,
656
00:36:05,463 --> 00:36:08,699
strategies, how we implement
657
00:36:09,967 --> 00:36:15,006
our solution
and how are we basically safeguarding our
658
00:36:16,674 --> 00:36:19,710
customer's assets,
given the rewards and the risks?
659
00:36:19,710 --> 00:36:23,314
And one of the things that we are very
conscious of is, for example,
660
00:36:24,782 --> 00:36:25,716
sometimes
661
00:36:25,716 --> 00:36:28,920
what is happening is that some operators
662
00:36:28,920 --> 00:36:33,424
might decide to take the open source
software for a component.
663
00:36:33,424 --> 00:36:37,128
Let's say a client may post,
in case of Ethereum,
664
00:36:37,562 --> 00:36:41,199
and they might actually start modifying it
665
00:36:41,766 --> 00:36:45,636
highly to just optimize it
for certain metrics.
It could be rewards,
666
00:36:45,636 --> 00:36:48,139
it could be performance,
it could be throughput.
667
00:36:48,139 --> 00:36:51,609
And it works great until it doesn't work
great anymore.
668
00:36:51,609 --> 00:36:54,612
Then let's say there is vulnerability
669
00:36:55,179 --> 00:36:59,116
network wide
or above in the original, source code.
670
00:36:59,750 --> 00:37:01,052
And now this is a challenge.
671
00:37:01,052 --> 00:37:07,291
This is a bad situation
because, the open source community
672
00:37:08,593 --> 00:37:11,729
test things and they offer things.
Then they are battle tested
673
00:37:12,396 --> 00:37:17,401
after many months of, you know,
going through rigorous, you know, tests
674
00:37:17,435 --> 00:37:21,806
through different situations,
and they offer a hotfix.
675
00:37:22,373 --> 00:37:24,242
And now this operator
676
00:37:25,843 --> 00:37:27,411
has this.
677
00:37:27,411 --> 00:37:31,048
It is possible in all likelihood
678
00:37:31,048 --> 00:37:34,051
that they cannot
just with a quick swap and,
679
00:37:34,418 --> 00:37:37,888
you know, benefit from this protection
against that vulnerability.
680
00:37:38,122 --> 00:37:42,994
Now they have to quickly modify
this new hotfix
681
00:37:42,994 --> 00:37:48,299
and try to operationalize it.
So,
they are essentially swapping it.
682
00:37:48,299 --> 00:37:51,302
Battle test
that software with a thinly tested one.
683
00:37:51,469 --> 00:37:55,172
And that actually introduces settlement
risk at the operator level.
684
00:37:55,172 --> 00:37:58,743
It has nothing to do with the network,
but it opens up for
685
00:38:00,244 --> 00:38:02,847
some sort of slashable offence
686
00:38:02,847 --> 00:38:05,850
or some other penalties in that sort.
687
00:38:06,150 --> 00:38:09,287
And we take these kind of risks
into consideration
688
00:38:09,320 --> 00:38:12,323
when we are making a decision
689
00:38:12,390 --> 00:38:15,393
about how we operationalize our staking.
690
00:38:17,061 --> 00:38:17,461
Yeah.
691
00:38:17,461 --> 00:38:19,964
Thank you Reza and Ben.
692
00:38:19,964 --> 00:38:22,333
You know, the way I think about risk.
693
00:38:22,333 --> 00:38:26,170
Because we work with clients that are both
694
00:38:26,470 --> 00:38:29,340
you know, node operators
such as yourselves,
695
00:38:29,340 --> 00:38:32,610
as well as institutions
that are looking to get involved
696
00:38:32,610 --> 00:38:36,580
in staking and,
you know, even some of the asset managers
697
00:38:36,580 --> 00:38:41,619
that, let's say, are looking to launch
or have launched staked Ethereum ETFs,
698
00:38:42,620 --> 00:38:44,388
there is a need
699
00:38:44,388 --> 00:38:47,458
for those institutional clients
to understand
700
00:38:47,858 --> 00:38:50,661
these risks as they're
conducting their due diligence.
701
00:38:50,661 --> 00:38:54,465
And one of the challenges that we faced
as we were doing
702
00:38:54,465 --> 00:38:58,002
some of this kind of work
for a lot of our clients, was
703
00:39:01,072 --> 00:39:02,907
you know, the existing
704
00:39:02,907 --> 00:39:07,311
SOC1 SOC2 attestations
that node operators had
705
00:39:08,145 --> 00:39:12,583
was not sufficient
for us to confirm that. Yes.
706
00:39:12,950 --> 00:39:18,022
You know, the risks around slashing
are adequately addressed by this node
707
00:39:18,022 --> 00:39:19,590
operator.
So, we would
708
00:39:19,590 --> 00:39:22,960
typically go into a lot more detail
in asking those questions
709
00:39:24,161 --> 00:39:27,798
and having a local anti-slashing
710
00:39:27,798 --> 00:39:31,402
database as well as how do you manage
doppelganger detection.
711
00:39:31,769 --> 00:39:34,271
Do you have DVT implementation, etc.
712
00:39:34,271 --> 00:39:36,240
Like,
we would ask a lot of those questions
713
00:39:36,240 --> 00:39:41,512
on top of just reviewing
like a SOC2 report or a SOC1 report.
714
00:39:42,113 --> 00:39:45,116
And I feel like for institutions,
715
00:39:45,783 --> 00:39:48,786
it is very hard for them
716
00:39:48,953 --> 00:39:52,690
to really get comfortable,
717
00:39:53,624 --> 00:39:56,627
even if we are coming in
and doing an independent,
718
00:39:56,627 --> 00:40:01,332
doing an assessment, like without having
a proper standard around these things
719
00:40:01,332 --> 00:40:05,336
and these, risk mitigation
requirements, it's very difficult for them
720
00:40:05,703 --> 00:40:10,775
to get comfortable on the infrastructure
and the controls that may exist to address
721
00:40:10,775 --> 00:40:15,913
those unique risks that are on slashing.
It is very technical, right. So,
722
00:40:16,914 --> 00:40:19,850
one of the areas that
723
00:40:19,850 --> 00:40:22,853
I'm going to focus
more on is the institutional side because,
724
00:40:23,754 --> 00:40:26,957
you know, the node operators,
they understand there is their day to day.
725
00:40:27,324 --> 00:40:31,595
They have people like
you guys who can dive deep into,
726
00:40:31,595 --> 00:40:34,698
you know, the repo
and have the whole history around that.
727
00:40:35,199 --> 00:40:39,470
But for institutions, as they are
looking to address these risks.
728
00:40:39,470 --> 00:40:42,339
As they look to get into staking,
729
00:40:42,339 --> 00:40:44,942
is really to look at some of the standards
730
00:40:44,942 --> 00:40:49,280
that are being developed around staking,
so similar
731
00:40:49,280 --> 00:40:53,717
to how you have your SOC1 and SOC2
for cloud service providers.
732
00:40:53,717 --> 00:40:56,954
There are, you know, there’s a CSA star,
733
00:40:57,521 --> 00:41:00,624
certification as well,
which is by the Cloud Security Alliance.
734
00:41:01,592 --> 00:41:06,831
Staking now also has a standard
that's been developed by,
735
00:41:07,231 --> 00:41:10,801
you know, the Liquid Collective
and the Illumio folks, which is really
736
00:41:11,068 --> 00:41:16,440
a lot of more mature node operators
coming together and understanding
737
00:41:16,440 --> 00:41:20,444
that one, there is a need
for decentralization around staking.
738
00:41:20,444 --> 00:41:24,415
And second is
how do we make this infrastructure
739
00:41:24,415 --> 00:41:28,552
more mature because when their clients
are reaching out to them
740
00:41:28,819 --> 00:41:32,089
and, you know, through us
most times, we’re asking
741
00:41:32,456 --> 00:41:37,094
a lot of the more technical questions
that go beyond SOC1 SOC2.
742
00:41:37,094 --> 00:41:41,732
So NORS switches
that node operator risk standard
743
00:41:42,600 --> 00:41:45,302
is now launched.
744
00:41:45,302 --> 00:41:46,337
It was actually launched.
745
00:41:46,337 --> 00:41:49,106
We're recording on October third.
746
00:41:49,106 --> 00:41:49,907
It was launched on
747
00:41:51,542 --> 00:41:54,311
September 30th I believe,
748
00:41:54,311 --> 00:41:58,649
which really helps institutions
get a lot more comfort on
749
00:41:58,983 --> 00:42:02,186
if a node operator is NORS certified
750
00:42:02,753 --> 00:42:06,957
that they have been through
an independent audit
751
00:42:07,291 --> 00:42:10,160
by qualified assessors,
752
00:42:10,160 --> 00:42:12,997
such as, you know, KPMG,
753
00:42:12,997 --> 00:42:18,002
that have come in, asked all the more
technical question, done independent
754
00:42:18,002 --> 00:42:21,205
testing around it and are now able to just
755
00:42:21,605 --> 00:42:24,542
take that NORS certification and
756
00:42:24,542 --> 00:42:26,644
you know, again, KPMG is not the one
757
00:42:26,644 --> 00:42:29,647
that certifies for NORS.
We just do the independent audit.
758
00:42:29,914 --> 00:42:33,918
But the liquid collective
is the one or the NORS
759
00:42:34,118 --> 00:42:38,122
Inc is the one that actually certifies
based on NORS standard. So
760
00:42:39,723 --> 00:42:43,928
the institutions can be rest assured
that if they are looking to work
761
00:42:43,928 --> 00:42:47,798
with an institutional staking provider
or node operator,
762
00:42:48,465 --> 00:42:51,969
that is NORS certified that they have gone
763
00:42:51,969 --> 00:42:54,972
through independent
audit and attestation work,
764
00:42:55,506 --> 00:42:56,941
to make sure that they have relevant
765
00:42:56,941 --> 00:43:00,244
controls in place and they don't
necessarily need to understand
766
00:43:00,945 --> 00:43:05,115
maybe the last 30 minutes of our
conversation in all technical details
767
00:43:05,349 --> 00:43:09,086
similar to how they would not
go into that level of detail
768
00:43:09,086 --> 00:43:11,589
when they're reviewing a SOC.
1 or SOC2 report,
769
00:43:11,589 --> 00:43:14,525
but because they're relying on the experts
to come in and do the audits.
770
00:43:14,525 --> 00:43:18,829
So, I want to highlight, you know, again,
from a risk standpoint, yes,
771
00:43:18,829 --> 00:43:23,901
there are risks that you guys, as node
operators, really need to mitigate.
772
00:43:23,901 --> 00:43:26,036
You need to have those controls in place.
773
00:43:26,036 --> 00:43:29,540
But from the institutional side
as they look to get into
774
00:43:29,540 --> 00:43:32,743
more institutional, in like staking
775
00:43:32,743 --> 00:43:35,980
and offering, let's say, ETPs around it.
776
00:43:37,715 --> 00:43:40,718
They don't need to necessarily
go through all of those
777
00:43:40,751 --> 00:43:46,290
technical questions as long as the staking
provider is NORS certified.
778
00:43:46,290 --> 00:43:49,827
And I would highly encourage,
you know, every
779
00:43:50,461 --> 00:43:53,831
staking operator
that is, maybe listening to this podcast,
780
00:43:54,732 --> 00:43:59,637
to look at NORS as a standard
and as a foundational level of capability
781
00:44:00,070 --> 00:44:03,540
that they would need to have in place
if they are looking to work
782
00:44:03,540 --> 00:44:07,978
with institutions, because a
standard is nothing unless it's adopted.
783
00:44:08,612 --> 00:44:11,215
There's some excellent points
on risk mitigation
784
00:44:11,215 --> 00:44:14,952
and just to round us out on this piece
here, I just want to add
785
00:44:15,252 --> 00:44:18,122
one other risk mitigation consideration
786
00:44:18,122 --> 00:44:21,759
here, is the emergence
of specialized insurance products
787
00:44:21,925 --> 00:44:26,330
that are designed to protect those who
participate in staking activities.
788
00:44:26,830 --> 00:44:30,768
So there are some providers out there
who provide these specialized
789
00:44:30,768 --> 00:44:31,669
insurance products.
790
00:44:31,669 --> 00:44:35,773
And some of the coverage types
include slashing protection.
791
00:44:35,973 --> 00:44:39,943
So that covers losses due to validator
mis-behaviour and technical failures.
792
00:44:40,310 --> 00:44:42,646
As Ben and Reza alluded to earlier,
793
00:44:42,646 --> 00:44:46,083
there's also coverage against smart
contract failure that protects against
794
00:44:46,083 --> 00:44:49,420
losses caused by bugs or vulnerabilities
at smart contracts
795
00:44:50,020 --> 00:44:52,456
that govern staking protocols,
and then finally,
796
00:44:52,456 --> 00:44:56,393
validator downtime as well,
which Ben and Reza also alluded to.
797
00:44:57,494 --> 00:44:58,362
And so, I think
798
00:44:58,362 --> 00:45:02,433
the advent of an extra layer of protection
799
00:45:02,433 --> 00:45:06,570
can help bridge that gap between TradFi
and the world of crypto.
800
00:45:08,706 --> 00:45:09,873
Really glad you brought that
801
00:45:09,873 --> 00:45:12,876
up, George, because I know,
802
00:45:12,976 --> 00:45:17,548
when I went for the launch
event of NORS, earlier this week,
803
00:45:17,981 --> 00:45:23,187
we did have, you know,
quite a few different insurance providers,
804
00:45:23,187 --> 00:45:27,424
even the traditional insurance providers
that were there to understand
805
00:45:27,558 --> 00:45:31,829
how institutional staking
operators are managing their risks.
806
00:45:31,829 --> 00:45:36,233
And, you know, they traditionally relied
on certain standards to underwrite
807
00:45:37,501 --> 00:45:41,338
the policies etc.
And it was good to see a lot of those
808
00:45:41,338 --> 00:45:44,875
insurance
providers in presence, at the event
809
00:45:44,875 --> 00:45:47,878
because they were also curious
to understand,
810
00:45:48,545 --> 00:45:51,749
again, they also don't want to go into
that level of technical details.
811
00:45:51,749 --> 00:45:55,119
So, they want to rely on something,
like a standard in place,
812
00:45:55,986 --> 00:45:57,521
to be able to underwrite.
813
00:45:57,521 --> 00:46:00,390
Fantastic gents.
Thank you all.
814
00:46:00,390 --> 00:46:01,759
Now let's move on to a newer
815
00:46:01,759 --> 00:46:05,229
topic and a concept in the staking world,
which is re-staking.
816
00:46:05,496 --> 00:46:08,799
Can you explain what re-staking
is and how exactly it works?
817
00:46:09,900 --> 00:46:11,535
Absolutely.
818
00:46:11,535 --> 00:46:13,570
so again, from a high level,
819
00:46:13,570 --> 00:46:16,573
Re-staking is actually fairly simple.
820
00:46:16,840 --> 00:46:19,843
At least on the, cover.
821
00:46:20,010 --> 00:46:22,146
So re-staking is about securing
822
00:46:22,146 --> 00:46:25,182
more than one protocol
with the same state.
Okay.
823
00:46:25,215 --> 00:46:29,019
Now, I think there's been a lot of noise
about re-staking lately
824
00:46:29,453 --> 00:46:31,321
with the launch of Eigen layer.
825
00:46:31,321 --> 00:46:34,291
So basically we're seeing re-staking
on Ethereum, which is very exciting.
826
00:46:34,291 --> 00:46:38,128
But for folks that are a little more
in the crypto space, in the Web3 space,
827
00:46:38,529 --> 00:46:39,930
this concept is not new.
828
00:46:39,930 --> 00:46:42,933
So, if you think about chains
like Polkadot, like cosmos SDK change,
829
00:46:43,200 --> 00:46:46,470
if you've heard of terms like replicated
security, shared security,
830
00:46:46,870 --> 00:46:49,873
it's the same concept.
So, you know,
831
00:46:50,040 --> 00:46:53,043
going back to the kind of basic,
832
00:46:53,877 --> 00:46:56,880
definition or framework
I had for understanding staking,
833
00:46:57,247 --> 00:47:01,451
the idea is the same stake is going
to be used for additional protocols.
834
00:47:02,553 --> 00:47:05,923
That does mean that I'll have to run
additional software, additional programs.
835
00:47:05,923 --> 00:47:08,692
So, you know,
I might want to secure Ethereum,
836
00:47:08,692 --> 00:47:10,260
but then the stake that I have
837
00:47:10,260 --> 00:47:13,230
that's allocated to Ethereum,
I might also want to use that
838
00:47:13,297 --> 00:47:15,499
to secure another protocol,
which would mean
839
00:47:15,499 --> 00:47:19,002
I have to run additional software
on that protocol.
840
00:47:19,536 --> 00:47:22,639
But the benefit for me
is that I don't have to go and find,
841
00:47:22,639 --> 00:47:26,243
let's say,
the equivalent of another amount of 32ft.
842
00:47:26,977 --> 00:47:31,381
So in other words, it's kind of like,
an efficient way to use your stake.
843
00:47:31,381 --> 00:47:33,350
You can kind of get multiple turns.
844
00:47:33,350 --> 00:47:35,319
A lot depends on the implementation.
845
00:47:35,319 --> 00:47:38,488
It doesn't always work so cleanly,
but that's generally the idea of restating
846
00:47:38,822 --> 00:47:42,259
securing multiple protocols
with the same state.
Awesome.
847
00:47:42,626 --> 00:47:44,528
And it sounds like a great way
to maximize returns,
848
00:47:44,528 --> 00:47:47,965
but any potential risks
or drawbacks associated with re-staking?
849
00:47:49,132 --> 00:47:51,034
Yeah, that's a great question.
850
00:47:51,034 --> 00:47:52,769
So yes, there are risks.
851
00:47:52,769 --> 00:47:55,906
I think any time you engage
across crypto or Web3,
852
00:47:56,173 --> 00:47:59,643
you touch almost anything,
you're going to incur some risks.
853
00:47:59,643 --> 00:48:02,613
So, you know, if you're depositing
your tokens into a smart contract,
854
00:48:02,779 --> 00:48:06,183
there's a risk there.
Now, generally
speaking, users
855
00:48:06,183 --> 00:48:09,152
certainly on Ethereum have
856
00:48:09,553 --> 00:48:11,455
become comfortable with smart contract
risks.
857
00:48:11,455 --> 00:48:13,257
There are ways to mitigate that.
858
00:48:13,257 --> 00:48:15,692
They can look at the smart contract
itself.
859
00:48:15,692 --> 00:48:17,728
In other words verify in the code.
860
00:48:17,728 --> 00:48:20,731
You can look at audits for smart contracts
861
00:48:20,797 --> 00:48:24,201
as a really rough kind of rule,
I wouldn't rely on this too much, but
862
00:48:24,201 --> 00:48:25,535
generally speaking,
863
00:48:25,535 --> 00:48:27,905
you know, if a contract has been around
for a long time,
864
00:48:27,905 --> 00:48:31,241
as Reza mentioned, kind of battle tested,
then used a lot and there have been
865
00:48:31,241 --> 00:48:34,244
no issues with it,
that should give you
some sort of reassurance.
866
00:48:34,544 --> 00:48:36,847
I'd actually use
this more in the opposite sense.
867
00:48:37,848 --> 00:48:38,982
I would not trust
868
00:48:38,982 --> 00:48:42,486
a new smart contract with no audits
ever been used, put it that way.
869
00:48:43,387 --> 00:48:45,022
So there's smart contract risk,
870
00:48:45,022 --> 00:48:48,692
but I think the big risk for folks
to think about is that, you know,
871
00:48:48,926 --> 00:48:52,863
effectively, you're opting in
to securing additional protocols.
So,
872
00:48:52,863 --> 00:48:57,000
if you think about this, as imagine that,
you know, someone replicated a bunch
873
00:48:57,000 --> 00:49:00,437
of versions of Ethereum on Eigen layer
and you just opted into every one of them.
874
00:49:01,238 --> 00:49:03,540
The slashing risk,
you're also multiplying.
875
00:49:03,540 --> 00:49:05,442
And you have to make certain assumptions
about the scenario.
876
00:49:05,442 --> 00:49:08,679
Like is there any tie back to Ethereum,
in which case
877
00:49:08,912 --> 00:49:11,915
you could have correlated events,
which would be a problem?
878
00:49:12,482 --> 00:49:15,552
And the other kind of nuance here
is that as of right
879
00:49:15,552 --> 00:49:19,456
now, there's no slashing on Eigen layer,
but that is coming, okay.
880
00:49:19,456 --> 00:49:23,460
So, we could do a whole podcast
on the history of Eigen layer.
881
00:49:23,727 --> 00:49:25,395
It's been a little long
in the tooth, to be frank.
882
00:49:26,463 --> 00:49:29,132
But slashing
is coming, and that's something that folks
883
00:49:29,132 --> 00:49:32,135
that are engaged with Eigen layer
today will need to
884
00:49:32,836 --> 00:49:36,506
take into account and should watch
what the slashing penalties look like
885
00:49:36,873 --> 00:49:38,008
and what they've opted into.
886
00:49:38,008 --> 00:49:41,144
Do they want to stay securing
those additional protocols,
887
00:49:41,144 --> 00:49:44,581
or do they want to rethink things
as the penalties become more apparent?
888
00:49:44,781 --> 00:49:47,451
There are also other risks,
but I think those are probably
889
00:49:47,451 --> 00:49:49,486
the big ones
that folks need to kind of grapple with.
890
00:49:49,486 --> 00:49:52,489
They're thinking about risk staking.
891
00:49:53,457 --> 00:49:55,292
Now, I want to go a bit off topic,
892
00:49:55,292 --> 00:49:58,261
if it is okay?
893
00:49:58,261 --> 00:49:59,896
One thing that really excites me
894
00:49:59,896 --> 00:50:03,834
about staking is, of course,
895
00:50:04,501 --> 00:50:09,706
you know, Ethereum,
at the source of security
896
00:50:09,840 --> 00:50:13,043
is basically lending security
to other networks.
897
00:50:13,910 --> 00:50:18,248
But also, you know, thinking
about scalability solutions, right?
898
00:50:18,248 --> 00:50:23,420
It's very expensive to build on layer
one on Ethereum at this point.
899
00:50:23,887 --> 00:50:28,425
So, you know, going off
Eigen layer and building on top of
900
00:50:28,425 --> 00:50:32,162
that could be one way,
but for a different reason. But,
901
00:50:34,664 --> 00:50:34,965
we were
902
00:50:34,965 --> 00:50:38,035
talking about the evolving risk
and how the network is actually evolving.
903
00:50:38,769 --> 00:50:41,038
There are lots of, work
904
00:50:41,038 --> 00:50:44,041
that is happening on the layer
twos, the podium.
905
00:50:45,308 --> 00:50:48,211
We see that, you know, there are
906
00:50:48,211 --> 00:50:52,883
massive developments on shared sequences
and, you know, talks about shared
907
00:50:52,949 --> 00:50:58,455
liquidity and peak confirmations
based rollups and things of that sort
908
00:50:58,722 --> 00:51:03,827
that we are going to see
that it is going to
909
00:51:05,429 --> 00:51:08,298
help with the adoption
910
00:51:08,298 --> 00:51:11,368
of building a different solutions
on Ethereum.
911
00:51:11,368 --> 00:51:15,205
Maybe not on the
layer one,
but on layer two at the lower price,
912
00:51:15,205 --> 00:51:18,208
but benefit from the finality,
913
00:51:18,842 --> 00:51:20,077
of the layer one.
914
00:51:20,077 --> 00:51:22,245
So Ethereum is doing two things.
915
00:51:22,245 --> 00:51:25,248
Then is security. Three is re-staking,
916
00:51:25,482 --> 00:51:28,418
offering finality to the, L2.
917
00:51:28,418 --> 00:51:32,823
So, as we can see, it is becoming more
prominent in the ecosystem
918
00:51:34,491 --> 00:51:35,725
to basically go to the next
919
00:51:35,725 --> 00:51:38,728
phase of the adoption
and in the adoption curve.
Yeah.
920
00:51:38,795 --> 00:51:42,399
Thanks, Ben and Reza,
those are great insights, not only on
921
00:51:42,399 --> 00:51:44,968
some of the risks
associated with re-staking,
922
00:51:44,968 --> 00:51:47,737
but also strategies to help
mitigate those risks.
923
00:51:47,737 --> 00:51:49,539
And Reza, I appreciate you
924
00:51:49,539 --> 00:51:53,410
highlighting a few of the aspects
of re-staking that really excite you.
925
00:51:53,643 --> 00:51:56,546
Unfortunately,
we have hit the end of today's episode.
926
00:51:56,546 --> 00:52:00,951
So once again, thank you, Ben and Reza
for joining us.
And to my resident
927
00:52:00,951 --> 00:52:04,788
co-hosts, Kunal and George, thank you
for helping us stick handle through
928
00:52:04,788 --> 00:52:09,893
another episode of KPMG in Canada's
state of digital assets podcast series.
929
00:52:10,127 --> 00:52:12,829
Until next time,
I'm Adam Rodricks. Bye for now.
00:00:00,433 --> 00:00:02,135
Hello everyone, and welcome back
2
00:00:02,135 --> 00:00:05,672
to KPMG in Canada's
State of Digital Assets podcast series.
3
00:00:05,972 --> 00:00:08,675
As always, I'm your host, Adam Rodricks,
and today
4
00:00:08,675 --> 00:00:12,879
we will be focusing on the evolution
of staking, risks, rewards and innovations
5
00:00:12,879 --> 00:00:15,215
with special guests,
Ben and Reza from Figment
6
00:00:15,215 --> 00:00:18,218
working in the field of blockchain
technology and staking.
7
00:00:18,718 --> 00:00:21,888
Starting with our KPMG participants,
I am so pleased to welcome back
8
00:00:21,888 --> 00:00:24,891
our Digital Asset Center of Excellence.
9
00:00:28,094 --> 00:00:28,628
Hi everyone!
10
00:00:28,628 --> 00:00:29,863
My name is Kunal Bhasin.
11
00:00:29,863 --> 00:00:33,933
I’m a partner with KPMG in Canada,
based in Toronto.
12
00:00:34,334 --> 00:00:38,138
I head our Digital Assets
Center of Excellence and focus
13
00:00:38,138 --> 00:00:42,008
a lot on our efforts on different aspects,
including staking.
14
00:00:42,008 --> 00:00:45,011
So happy to be here
and having this discussion today.
15
00:00:45,278 --> 00:00:47,247
Thank you Kunal.
And Adam.
16
00:00:47,247 --> 00:00:48,481
And my name is George Djuric.
17
00:00:48,481 --> 00:00:51,518
I'm a manager with our Digital Assets
Center of Excellence, also
18
00:00:51,518 --> 00:00:56,189
based out of Toronto, and I focus on
all things crypto related at the firm.
19
00:00:56,189 --> 00:00:59,325
That typically entails working
with three different types of clients
20
00:00:59,692 --> 00:01:04,798
your traditional institutional types,
your crypto native types, and regulators.
21
00:01:05,265 --> 00:01:08,301
As it relates to staking,
we've been seeing a lot more institutional
22
00:01:08,334 --> 00:01:12,806
interest in this area, so really excited
to dive into it with the Figment team.
23
00:01:14,274 --> 00:01:15,909
Fantastic
Thank you both for
24
00:01:15,909 --> 00:01:19,646
being here, and we are beyond excited
to welcome our guests from Figment.
25
00:01:19,913 --> 00:01:22,982
Could you each start by please
introducing yourselves as well?
26
00:01:22,982 --> 00:01:25,318
Maybe I'll go to Ben first.
27
00:01:25,318 --> 00:01:27,353
Hey folks.
So as mentioned, my name is Ben.
28
00:01:27,353 --> 00:01:28,721
Ben Thalman.
29
00:01:28,721 --> 00:01:31,357
I'm a senior protocol
specialist at Figment.
30
00:01:31,357 --> 00:01:35,128
I cover the Ethereum ecosystem,
so everything that happens on the base
31
00:01:35,128 --> 00:01:38,498
layer of Ethereum is very much of interest
to me.
We've got an update coming,
32
00:01:39,365 --> 00:01:41,067
early next year called Petra.
33
00:01:41,067 --> 00:01:42,802
But then, of course, everything
built on top.
34
00:01:42,802 --> 00:01:46,072
So you've heard things like MEV
maximalist, tractable value,
35
00:01:46,573 --> 00:01:48,575
scaling efforts, Altuz staking.
36
00:01:48,575 --> 00:01:51,511
All of that is in my wheelhouse.
37
00:01:51,511 --> 00:01:54,481
And before joining Figment,
I was in TradFi for about ten years.
38
00:01:54,914 --> 00:01:55,982
Hello everyone.
39
00:01:55,982 --> 00:01:58,952
I'm really happy to be here.
I'm Reza from Figment.
40
00:01:59,119 --> 00:02:01,488
I am part of the product team, and
41
00:02:02,622 --> 00:02:04,824
my main focus at Figment is
42
00:02:04,824 --> 00:02:09,262
our tier zero networks,
which are Ethereum and Solana.
43
00:02:09,262 --> 00:02:15,502
I work very closely with Ben,
and we build stuff to make sure
44
00:02:15,502 --> 00:02:19,639
that our operations are smooth
and, are excellent.
45
00:02:21,674 --> 00:02:22,375
Fantastic.
46
00:02:22,375 --> 00:02:22,942
Thank you both
47
00:02:22,942 --> 00:02:26,679
so much for being here today.
Now,
we talked a little bit about what you do.
48
00:02:26,980 --> 00:02:30,150
Can you give us a brief introduction
as to what Figment does?
49
00:02:30,450 --> 00:02:33,453
Figment is an institutional
staking service provider.
50
00:02:33,853 --> 00:02:37,157
We offer staking infrastructure
on over three dozen networks.
51
00:02:38,191 --> 00:02:40,059
Our focus is mainly institutional.
52
00:02:40,059 --> 00:02:44,164
We're non-custodial, so we don't actually
take control of our customers tokens.
53
00:02:44,898 --> 00:02:47,567
You know, as Reza mentioned in his intro,
54
00:02:47,567 --> 00:02:50,603
Ethereum and Solana
are some of our larger networks
55
00:02:50,603 --> 00:02:53,940
that we focus on.
But as I say, we're on
something like 40 networks.
56
00:02:54,841 --> 00:02:56,342
and that's specifically for staking.
57
00:02:56,342 --> 00:02:59,245
We also offer some ancillary services.
58
00:02:59,245 --> 00:03:02,749
So, I think all told, we're probably on,
I don't know, close
59
00:03:02,749 --> 00:03:03,783
to running the infrastructure
60
00:03:03,783 --> 00:03:07,954
on close to 100 networks, but just around
40 of those are specifically for staking.
61
00:03:09,956 --> 00:03:10,957
Thanks so much, Ben.
62
00:03:10,957 --> 00:03:11,491
You know,
63
00:03:11,491 --> 00:03:13,026
you mentioned staking so many times.
64
00:03:13,026 --> 00:03:14,928
I'm going to have to take it
back to the beginning.
65
00:03:14,928 --> 00:03:18,031
Can you define staking and explain
its role in validating
66
00:03:18,031 --> 00:03:21,034
transactions
in a proof of stake blockchain?
67
00:03:21,167 --> 00:03:22,202
Absolutely.
68
00:03:22,202 --> 00:03:24,871
So, you know, I think from a very like 101
69
00:03:24,871 --> 00:03:27,840
basic understanding,
the way I like to think about staking
70
00:03:28,141 --> 00:03:32,412
is that it's effectively an agreement
between a token holder and a protocol.
71
00:03:32,946 --> 00:03:37,150
And so, the idea is if I'm a token holder
and I want to get involved with staking,
72
00:03:37,483 --> 00:03:41,721
I will perform certain tasks on
behalf of the network like Ethereum.
73
00:03:41,988 --> 00:03:43,790
And by the way, it is just an aside.
74
00:03:43,790 --> 00:03:45,858
Everything I say is probably going
to relate back to Ethereum.
75
00:03:45,858 --> 00:03:48,228
So heavy Ethereum references coming.
76
00:03:48,228 --> 00:03:50,563
But essentially,
I think of it like an agreement.
77
00:03:50,563 --> 00:03:54,567
Okay, so if I perform
the task as expected, I will get a reward.
78
00:03:54,734 --> 00:03:58,371
And that's what Ethereum or the protocol
kind of promises to me.
79
00:03:58,605 --> 00:04:02,175
And I promise to perform the tasks
appropriately.
80
00:04:02,542 --> 00:04:07,113
On Ethereum, that means I will test
correctly and in a timely manner.
81
00:04:07,247 --> 00:04:08,681
As an example,
82
00:04:08,681 --> 00:04:11,184
the whole issue with the state, the tokens
83
00:04:11,184 --> 00:04:14,187
that I put up, I'm essentially agreeing
84
00:04:14,454 --> 00:04:17,890
that I give Ethereum access to my tokens
for breaking rules.
85
00:04:17,890 --> 00:04:20,593
In other words,
they can take some of those tokens away.
86
00:04:20,593 --> 00:04:23,796
So again, I mentioned the timeliness
and correctness of an attestation.
87
00:04:24,264 --> 00:04:27,267
If I get that wrong,
some of my tokens will be taken away.
88
00:04:27,300 --> 00:04:30,637
And if I engage in malicious behaviour,
if I attempt to attack the network,
89
00:04:31,738 --> 00:04:33,172
even more tokens will be taken away.
90
00:04:33,172 --> 00:04:36,643
So those are a couple of examples,
but a high level or a 101, I think of it
91
00:04:36,643 --> 00:04:39,646
as an agreement between the token holder
and the protocol.
92
00:04:39,779 --> 00:04:40,380
Got it.
93
00:04:40,380 --> 00:04:43,650
And how does staking differ
from the proof of work consensus mechanism
94
00:04:43,650 --> 00:04:46,653
used by Bitcoin
and other cryptocurrencies?
95
00:04:46,953 --> 00:04:48,421
Great question.
96
00:04:48,421 --> 00:04:50,790
So, I like analogies,
especially from a 1 to 1 level.
97
00:04:50,790 --> 00:04:53,960
So, when I think about a proof
of stake versus proof of work.
98
00:04:54,394 --> 00:04:57,397
For proof of work,
I like the analogy of a race.
99
00:04:57,463 --> 00:04:59,332
And for proof of stake, I like a lottery.
100
00:04:59,332 --> 00:05:02,502
So, when you think about proof of work,
it's a lot like a race.
101
00:05:02,969 --> 00:05:06,739
Miners are racing each other
and the first miner to get over the finish
102
00:05:06,739 --> 00:05:11,311
line gets to produce a block, and
the block is just a set of transactions.
103
00:05:11,311 --> 00:05:12,445
So, you know, to
104
00:05:12,445 --> 00:05:16,382
tie back to a real world example, and
you can think of logging on to your bank
105
00:05:16,683 --> 00:05:18,918
and you see a bunch of transactions
that have happened,
106
00:05:18,918 --> 00:05:20,820
and you can see how your balances changed.
107
00:05:20,820 --> 00:05:22,622
Now obviously, the bank is centralized.
108
00:05:22,622 --> 00:05:24,691
We're talking about decentralization,
109
00:05:24,691 --> 00:05:27,660
but that's a helpful analogy to kind of
think of a block of transactions.
110
00:05:28,261 --> 00:05:31,731
So again, thinking about proof of work,
think of a race.
111
00:05:32,131 --> 00:05:34,367
What's actually happening
obviously is not a physical race,
112
00:05:34,367 --> 00:05:38,671
but there is a race between miners
and they're competing on essentially
113
00:05:38,671 --> 00:05:42,742
what boils down to a puzzle that they need
to solve using computational resources.
114
00:05:43,076 --> 00:05:45,778
And the first, again,
the first one to win that
115
00:05:45,778 --> 00:05:48,781
race gets to build
the next block on the chain.
116
00:05:48,915 --> 00:05:51,551
Now, I mentioned
proof of stake is more like a lottery.
117
00:05:51,551 --> 00:05:55,755
So, you can think of every stake
or validator on Ethereum, let's say
118
00:05:56,122 --> 00:05:57,123
as a lottery ticket.
119
00:05:58,191 --> 00:06:00,960
Every
12 seconds, a new proposer is chosen.
120
00:06:00,960 --> 00:06:03,696
So, in other words,
a lottery ticket is selected
121
00:06:03,696 --> 00:06:06,699
and whoever has that ticket
gets to propose the block.
122
00:06:07,500 --> 00:06:10,503
Now, a little bit of a nuance here,
123
00:06:10,503 --> 00:06:13,740
in terms of the probability of
being chosen on a proof of stake network
124
00:06:13,740 --> 00:06:17,910
to propose the next block of transactions,
it's proportional to your state.
125
00:06:18,277 --> 00:06:21,280
So, you can think of this as someone
who buys more lottery tickets than someone
126
00:06:21,280 --> 00:06:25,151
else, will have a higher likelihood
of being chosen to propose the block.
127
00:06:25,518 --> 00:06:28,221
But that's basically from a high level,
128
00:06:28,221 --> 00:06:30,423
stake is determining
who gets to propose the next block.
129
00:06:30,423 --> 00:06:33,426
Whereas on proof of work, it's
whoever wins that
130
00:06:34,394 --> 00:06:37,397
computer algorithm,
whoever solves that puzzle first.
131
00:06:37,830 --> 00:06:41,834
And if I can just add to that as well and
build off of what Ben is explaining here.
132
00:06:41,834 --> 00:06:45,438
One of the key differences
between the two consensus mechanism is
133
00:06:46,372 --> 00:06:47,640
energy intensiveness.
134
00:06:47,640 --> 00:06:51,511
So typically, proof of stake consensus
mechanisms
135
00:06:52,178 --> 00:06:55,448
produces far less energy
than proof of work systems.
136
00:06:55,848 --> 00:06:59,452
And so, it's typically been positioned
as a more and better
137
00:06:59,552 --> 00:07:02,522
environmentally friendly
consensus mechanism.
138
00:07:02,955 --> 00:07:06,993
And I think what a lot of people
forget as well is that Ethereum, prior
139
00:07:06,993 --> 00:07:11,364
to September 2022, is actually operating
on a proof of work model,
140
00:07:11,898 --> 00:07:15,768
and they had moved over to proof of stake
only two years ago.
141
00:07:15,768 --> 00:07:17,837
And I think a lot of folks forget that
142
00:07:17,837 --> 00:07:20,973
it's only been two years
since this has happened, and today
143
00:07:21,541 --> 00:07:25,711
I believe it's a little over
25% of all Ether is staked currently,
144
00:07:26,112 --> 00:07:29,315
which is about $90 billion of value
securing this network.
145
00:07:29,315 --> 00:07:33,219
So, I think that just underscores
the growing confidence in proof of stake
146
00:07:33,219 --> 00:07:34,053
systems as well.
147
00:07:35,555 --> 00:07:38,558
To add to Ben’s great analogy
148
00:07:39,425 --> 00:07:42,061
of race versus lottery.
149
00:07:42,061 --> 00:07:44,764
The caveats here
that this lottery is not passive.
150
00:07:44,764 --> 00:07:47,133
It's not that, you know,
you buy the ticket and,
151
00:07:47,133 --> 00:07:49,936
you know, you just win something.
152
00:07:49,936 --> 00:07:52,305
Once you select it,
153
00:07:52,305 --> 00:07:55,608
to produce that block,
whether it is Solana or Ethereum,
154
00:07:56,943 --> 00:08:00,413
there is a competition
over operational excellence.
155
00:08:00,880 --> 00:08:04,050
And the rewards
that you get really depends on that.
156
00:08:04,050 --> 00:08:07,854
In other words, you can actually change
the size of the lottery that you win
157
00:08:08,221 --> 00:08:10,890
by your operations and by your set up.
158
00:08:10,890 --> 00:08:13,893
So in the stadium, in that 12 seconds,
159
00:08:14,694 --> 00:08:19,632
you know, you basically propose a block
that has the highest value,
160
00:08:19,632 --> 00:08:22,635
but that block is given to you
by some builder, of course.
161
00:08:23,069 --> 00:08:26,472
But if you don't do it within that
12 second, that's a missed opportunity.
162
00:08:26,839 --> 00:08:32,445
In Solana, this is even more massive
because you have a fraction of that time
163
00:08:32,945 --> 00:08:35,948
and you're actually building the block
yourself.
164
00:08:36,148 --> 00:08:39,785
And so, your operations matter
a lot in terms of how much rewards
165
00:08:39,785 --> 00:08:41,287
you're going to get at the end of the day.
166
00:08:43,656 --> 00:08:44,423
Fantastic.
167
00:08:44,423 --> 00:08:45,825
Thank you for crystallizing that for us.
168
00:08:45,825 --> 00:08:51,130
You know, moving forward, you hear a lot
about validators, delegators and rewards.
169
00:08:51,130 --> 00:08:54,834
So, I'm hoping you can explain
the key components of staking.
170
00:08:56,736 --> 00:09:00,540
I think if I could start on that one,
I think, in my mind
171
00:09:00,573 --> 00:09:03,543
when we talk about staking, I think really
172
00:09:03,609 --> 00:09:06,112
one of the most important distinctions
in the two actors
173
00:09:06,112 --> 00:09:08,881
that are really important
are stakers and operators.
174
00:09:08,881 --> 00:09:11,551
And so, you know, you can say stakers,
175
00:09:11,551 --> 00:09:14,520
you can say delegators,
and you can say operators or validators.
176
00:09:14,820 --> 00:09:18,257
But I think the distinction
is essentially the token holder.
177
00:09:18,724 --> 00:09:21,427
And then the one actually
running the infrastructure, running
178
00:09:21,427 --> 00:09:24,430
the software that does those tasks
I mentioned earlier.
179
00:09:24,830 --> 00:09:29,001
And, you know, there are some networks
known as delegated proof of stake networks
180
00:09:29,001 --> 00:09:33,472
that are built around this concept,
recognizing that not every token holder,
181
00:09:33,472 --> 00:09:36,609
although they want to be involved
with staking and helping the network
182
00:09:36,609 --> 00:09:39,879
reach consensus, they don't actually,
necessarily, want to run the software.
183
00:09:40,212 --> 00:09:43,015
And so, networks like Solana that Reza
184
00:09:43,015 --> 00:09:46,018
mentioned, that's a good example
of a delegated proof of stake network.
185
00:09:46,018 --> 00:09:50,289
And if you go on and explore for Solana by
the way, you can often see the operator.
186
00:09:50,289 --> 00:09:51,424
You can see how much they have
187
00:09:51,424 --> 00:09:54,427
of their own token stake
and then how much has been delegated.
188
00:09:54,794 --> 00:09:55,861
Ethereum's a little different
189
00:09:55,861 --> 00:09:59,665
in the sense that it wasn't built
with this concept of delegation.
190
00:09:59,665 --> 00:10:04,770
So, anyone who wants to run a validator
or operate on Ethereum,
191
00:10:05,371 --> 00:10:08,040
they have to actually go ahead
and activate a validate.
192
00:10:08,040 --> 00:10:09,675
Every validator takes 32e.
193
00:10:11,010 --> 00:10:12,178
But even
194
00:10:12,178 --> 00:10:15,581
though Ethereum wasn't built
with this delegated proof of stake model,
195
00:10:16,082 --> 00:10:19,051
that is actually what's going on
in the background in a lot of cases,
196
00:10:19,051 --> 00:10:21,921
as I mentioned, you know,
Figment is a staking service provider.
197
00:10:21,921 --> 00:10:25,625
We do
run validators on Ethereum for customers.
198
00:10:26,225 --> 00:10:28,861
And there are other things too,
like liquid staking protocols
199
00:10:28,861 --> 00:10:30,930
that basically do
the same thing on Ethereum.
200
00:10:30,930 --> 00:10:34,300
So even though Ethereum doesn't
look like a delegated proof
201
00:10:34,300 --> 00:10:37,403
of stake system,
there is delegation happening
202
00:10:37,570 --> 00:10:40,573
kind of on the back
end of Ethereum as well.
203
00:10:41,240 --> 00:10:43,542
Again, I'm going
204
00:10:43,542 --> 00:10:46,545
to add to what Ben said and again,
205
00:10:47,246 --> 00:10:48,881
that this is basically some
206
00:10:48,881 --> 00:10:51,917
cleansing across
different proof of stake networks,
207
00:10:51,917 --> 00:10:57,256
which is baked in their protocol,
like in Solana and in Ethereum, it is not.
208
00:10:57,256 --> 00:10:57,990
And it
209
00:10:59,091 --> 00:11:02,094
sometimes is rooted in their ethos.
210
00:11:02,361 --> 00:11:05,131
Like for Ethereum,
211
00:11:05,131 --> 00:11:08,100
the idea of decentralization,
212
00:11:08,701 --> 00:11:10,569
happens like they want
213
00:11:10,569 --> 00:11:14,407
people to run these nodes
on consumer grade hardware.
214
00:11:15,441 --> 00:11:17,910
And because of that, you know,
215
00:11:17,910 --> 00:11:22,214
the whole idea was that start delegation,
you are going to take a more active role.
216
00:11:22,214 --> 00:11:25,217
That's the design versus in Solana,
217
00:11:25,685 --> 00:11:28,120
it's all about speed. It's about tuple.
218
00:11:28,120 --> 00:11:32,224
And you cannot run that
on a consumer grade hardware you need.
219
00:11:32,358 --> 00:11:35,361
So that's why they actually have the specs
for the type of hardware
220
00:11:35,461 --> 00:11:36,896
that you're going to run.
221
00:11:36,896 --> 00:11:39,298
And that's why
this distinction was very important.
222
00:11:39,298 --> 00:11:42,301
Not everybody could run that
and have that operation.
223
00:11:42,435 --> 00:11:48,507
So that that's why the delegation
is an important role.
224
00:11:48,507 --> 00:11:52,344
And one more thing that I want to mention
225
00:11:52,344 --> 00:11:56,716
is that the more actors in this space,
let's say in
226
00:11:56,716 --> 00:11:57,750
Ethereum than just delegated to Stakers,
we have, like builders and searchers
227
00:11:57,750 --> 00:12:03,856
that their job is actually,
building the block and the validate
228
00:12:03,856 --> 00:12:07,059
is basically outsourced to them
229
00:12:07,059 --> 00:12:10,262
when it comes to Ethereum.
230
00:12:11,731 --> 00:12:14,734
So they're
working with these different actors.
231
00:12:15,134 --> 00:12:20,406
Basically making strategic decisions
232
00:12:20,673 --> 00:12:25,277
on how to engage with them
is one part of our job as a node operator.
233
00:12:25,711 --> 00:12:26,345
Got it.
234
00:12:26,345 --> 00:12:29,482
Now, staking
does seem like an attractive proposition,
235
00:12:29,482 --> 00:12:32,852
but if I'm understanding it correctly,
it's not completely without its risks.
236
00:12:32,852 --> 00:12:36,622
So, can you give us an overview
of the risks involved in staking?
237
00:12:37,757 --> 00:12:39,091
Absolutely.
238
00:12:39,091 --> 00:12:41,794
So, I think I might kind of tee
this up generally
239
00:12:41,794 --> 00:12:44,797
and then I'll get into Ethereum
as a, as an example.
240
00:12:44,964 --> 00:12:49,535
So, I think it's important to understand
that there in my mind
241
00:12:49,535 --> 00:12:52,838
two broad categories, of penalties.
242
00:12:53,372 --> 00:12:55,775
One is implicit and the other is explicit.
243
00:12:55,775 --> 00:12:59,145
I think of implicit as I'm thinking
of opportunity cost.
So as an example
244
00:12:59,645 --> 00:13:01,180
on Ethereum,
245
00:13:01,180 --> 00:13:04,617
when you're selected to propose a block,
if you happen to miss that,
246
00:13:04,617 --> 00:13:05,985
in other words, you don't propose
247
00:13:05,985 --> 00:13:09,588
a block when you're assigned
to, there's no explicit penalty with that.
248
00:13:10,022 --> 00:13:11,824
The penalty is the opportunity cost.
249
00:13:11,824 --> 00:13:15,895
In other words, when you propose a block,
you get more rewards than you do
250
00:13:15,895 --> 00:13:19,532
for a testing, let's say, which is another
task
validators are required to do.
251
00:13:20,032 --> 00:13:23,636
So, the penalty there, in a sense, is
you don't have it
252
00:13:23,636 --> 00:13:27,072
taken away, but you really don't
want to be missing those blocks.
253
00:13:27,072 --> 00:13:29,775
That's kind of
what Reza alluded to earlier.
254
00:13:29,775 --> 00:13:30,976
So that's what I call implicit.
255
00:13:30,976 --> 00:13:34,747
However, there are also explicit penalties
where you actually do have
256
00:13:34,747 --> 00:13:36,549
some of your tokens taken away.
257
00:13:36,549 --> 00:13:37,850
And as I mentioned at the outset,
you know,
258
00:13:37,850 --> 00:13:40,853
when I kind of framed things
as there’s this agreement
259
00:13:41,053 --> 00:13:43,923
between the token holder
when they’re taking on the protocol,
260
00:13:43,923 --> 00:13:47,593
if you fail to do certain duties,
you can have tokens taken away.
261
00:13:48,227 --> 00:13:51,230
To make this a little more concrete,
I try and keep this short,
262
00:13:51,297 --> 00:13:54,633
but let’s talk real quick about the risks
and penalties on Ethereum.
263
00:13:55,000 --> 00:13:59,738
And I'll go in order of,
just the magnitude of these risks.
264
00:14:00,306 --> 00:14:00,973
So first,
265
00:14:00,973 --> 00:14:05,010
the lowest kind of risk that you can face
are what I call performance penalties,
266
00:14:05,344 --> 00:14:08,347
some people also refer to them
as downtime penalties.
267
00:14:08,881 --> 00:14:12,818
So, one of the things you have to do
as a validator on Ethereum is a test.
268
00:14:12,952 --> 00:14:15,454
And a test
just basically means as a validator,
269
00:14:15,454 --> 00:14:17,923
this is what Ethereum state
looks like to me. Okay.
270
00:14:17,923 --> 00:14:21,727
And you actually report on three different
items when you make that attestation.
271
00:14:23,162 --> 00:14:25,064
Two of these items, if you
272
00:14:25,064 --> 00:14:28,667
don't respond in a timely way
or in a correct way, carry a penalty.
273
00:14:29,335 --> 00:14:31,170
Okay. And this is where downtime
penalties comes in.
274
00:14:31,170 --> 00:14:34,740
If you're a validator, let's say
is totally offline, you're going to start
275
00:14:34,740 --> 00:14:37,743
to accrue these penalties.
Again,
just to put this in context,
276
00:14:38,277 --> 00:14:42,681
validators on Ethereum are asked to attest
225 times per day.
277
00:14:43,215 --> 00:14:45,784
So, at roughly around 6.4 minutes, you're
278
00:14:45,784 --> 00:14:48,787
expected to attest, okay.
279
00:14:49,221 --> 00:14:51,724
On the other side
though in terms of rewards
280
00:14:51,724 --> 00:14:54,560
for these three duties
you do, you will gain rewards
281
00:14:54,560 --> 00:14:57,663
if you do them again in a timely manner
and in a correct manner.
282
00:14:58,130 --> 00:15:00,799
So just to note,
there's a bit of an asymmetry here.
283
00:15:00,799 --> 00:15:04,036
If you were offline,
let's say for an hour to gain back
284
00:15:04,303 --> 00:15:08,073
the rewards that you've lost,
you would have to be online
285
00:15:08,073 --> 00:15:10,409
for slightly less than an hour
because there's asymmetry.
286
00:15:10,409 --> 00:15:12,378
Anyway, that's a bit of a nuance.
287
00:15:12,378 --> 00:15:16,048
And just again, to put this into context,
if you're offline for an hour,
288
00:15:16,048 --> 00:15:19,718
the cost in dollars is around 15 to $0.20.
289
00:15:20,185 --> 00:15:23,188
So, we're talking
not massive penalties, okay.
290
00:15:23,822 --> 00:15:27,259
The next set of penalties
is referred to as inactivity.
291
00:15:28,227 --> 00:15:29,695
Now this is a special
292
00:15:29,695 --> 00:15:32,698
situation, a little bit complicated,
so just bear with me.
293
00:15:32,865 --> 00:15:35,868
There's this concept of finalization
on Ethereum.
294
00:15:36,035 --> 00:15:40,773
The idea with finalization
is that once a block becomes finalized
295
00:15:41,407 --> 00:15:46,612
and technically you actually finalize
per epoch, there are 32 slots in an epoch.
296
00:15:46,712 --> 00:15:49,682
Typically,
there are 32 blocks in an epoch.
297
00:15:50,416 --> 00:15:53,852
That full epoch will become finalized
at the same time.
298
00:15:53,852 --> 00:15:57,456
So, in other words, Ethereum moves
in this kind of cadence of 32
299
00:15:57,756 --> 00:16:00,693
slots at a time, or roughly 32 blocks.
300
00:16:00,693 --> 00:16:03,696
But once a block itself
has become finalized,
301
00:16:04,730 --> 00:16:08,033
the likelihood that it becomes reverted,
in other words, history
302
00:16:08,033 --> 00:16:11,670
kind of undoes itself is very, very low.
Now, there are more nuances here,
303
00:16:11,670 --> 00:16:14,239
and it has to do with Ethereum's
consensus mechanism.
304
00:16:14,239 --> 00:16:15,341
I'm going to push that aside for now.
305
00:16:15,341 --> 00:16:17,943
We can get into it later,
but we really get into the weeds
306
00:16:17,943 --> 00:16:19,545
and nitty gritty of Ethereum
if we go there.
307
00:16:19,545 --> 00:16:22,114
So, I'm just going to going
to leave it aside for now.
308
00:16:22,114 --> 00:16:22,915
But the point is,
309
00:16:23,882 --> 00:16:25,884
Ethereum expects to finalize
310
00:16:25,884 --> 00:16:30,089
roughly every 13 minutes.
But if there's a period
311
00:16:30,689 --> 00:16:34,560
of more than four epochs
in which Ethereum has not finalized.
312
00:16:34,560 --> 00:16:38,030
So, if you enter the fifth epoch
and Ethereum is not finalized,
313
00:16:38,430 --> 00:16:40,432
you enter inactivity.
314
00:16:40,432 --> 00:16:44,970
And what happens with inactivity
is that non-performing validators,
315
00:16:44,970 --> 00:16:46,171
in addition to the penalties,
316
00:16:46,171 --> 00:16:49,141
I just talked about performance penalties
or downtime penalties.
317
00:16:49,575 --> 00:16:52,578
There's an additional penalty
called inactivity leak.
318
00:16:53,479 --> 00:16:57,216
And this penalty, the way it looks
is it starts off small, similar
319
00:16:57,216 --> 00:17:01,820
in magnitude to the performance penalties,
but it increases very quickly, okay.
320
00:17:01,820 --> 00:17:04,923
So, to give a sense,
if you had a day in inactivity leak,
321
00:17:05,524 --> 00:17:07,459
your Ethereum balance
at the end of that day,
322
00:17:07,459 --> 00:17:11,764
if you're a non-performing validator
would be about 99.9% of your balance.
323
00:17:12,197 --> 00:17:15,601
Okay, so not really a huge difference,
but 0.1% under the statement.
324
00:17:16,902 --> 00:17:19,938
After a week that number is about 93%.
325
00:17:19,938 --> 00:17:22,207
So now 7% of it is taken.
326
00:17:22,207 --> 00:17:25,411
After two weeks, we're at about 74%.
327
00:17:25,778 --> 00:17:28,547
And after three weeks about half of it
is taken away.
328
00:17:28,547 --> 00:17:31,784
So, what I'm trying to get across
is it starts very low,
329
00:17:32,184 --> 00:17:35,187
but it ratches up very quickly.
330
00:17:35,320 --> 00:17:38,323
Just bear with me
almost through the risks here on Ethereum,
331
00:17:38,323 --> 00:17:41,326
I just want to mention two more things.
First,
332
00:17:41,460 --> 00:17:44,930
the goal of inactivity leak
and kind of give some context around this.
333
00:17:44,930 --> 00:17:47,232
The idea is
334
00:17:47,232 --> 00:17:48,901
Ethereum not finalizing is
335
00:17:48,901 --> 00:17:51,904
an abnormal situation
and it's not a healthy one.
336
00:17:51,937 --> 00:17:56,041
Ethereum needs to get back to finalizing
because it's finalizing is important
337
00:17:56,041 --> 00:17:57,076
for all kinds of reasons.
338
00:17:57,076 --> 00:18:00,345
One of the big ones is for the user’s
sake.
339
00:18:00,345 --> 00:18:04,149
So, the idea with inactivity leak is what
we need to do.
We being Ethereum,
340
00:18:04,516 --> 00:18:08,787
is to weed out the non-performing
validators, reduce their balance
341
00:18:09,121 --> 00:18:12,124
to such a point
that we can get back to finalization.
342
00:18:12,758 --> 00:18:14,159
And as a reminder, on Ethereum,
343
00:18:14,159 --> 00:18:16,929
finalization
takes two thirds of validators.
344
00:18:16,929 --> 00:18:18,197
So what? What happens is
345
00:18:19,198 --> 00:18:22,201
validators that are performing
during inactivity leak,
346
00:18:22,301 --> 00:18:24,303
their balance stays the same
even if they're performing
347
00:18:24,303 --> 00:18:26,071
so they don't actually get rewards.
The penalties
348
00:18:26,071 --> 00:18:29,041
and rewards offset each other,
but their balance stays the same.
349
00:18:29,341 --> 00:18:32,344
Non-performing
validators have the performance penalties,
350
00:18:32,344 --> 00:18:36,615
but they also get inactivity leak,
so their relative difference increases.
351
00:18:36,949 --> 00:18:40,352
Performance validators
now represent more and more voting weight
352
00:18:40,352 --> 00:18:44,123
on Ethereum, and non-performing validators
represent less and less.
353
00:18:44,123 --> 00:18:47,126
The idea is if we can drain away
354
00:18:47,359 --> 00:18:50,028
the non-performing validators, eventually
355
00:18:50,028 --> 00:18:53,031
we will get back to finalization
and that's the goal of an activity
356
00:18:53,999 --> 00:18:58,203
I would say is somewhere
between non-performance risk or penalties
357
00:18:58,637 --> 00:19:02,441
and then slashing penalties.
I would say
that slashing penalties, don't worry.
358
00:19:02,441 --> 00:19:06,879
The last risk that I want to address
359
00:19:08,580 --> 00:19:10,616
has the potential to be the most severe.
360
00:19:11,950 --> 00:19:14,253
So slashing, real quick.
361
00:19:14,253 --> 00:19:16,021
And this is similar across most networks.
362
00:19:16,021 --> 00:19:18,657
The idea is equivocation
or double signing.
363
00:19:18,657 --> 00:19:21,727
In other words, as a validator,
what you're doing is basically
364
00:19:23,061 --> 00:19:25,831
attesting
or saying that there are two states
365
00:19:25,831 --> 00:19:28,800
of reality or more at the same time.
And that's a problem.
366
00:19:29,268 --> 00:19:29,768
You can't do that.
367
00:19:29,768 --> 00:19:32,738
It's kind of like, if you think for
an analogy here, kind of like perjury.
368
00:19:32,738 --> 00:19:35,541
If you're testifying in court
or something, you're kind of saying
369
00:19:35,541 --> 00:19:38,544
that there are two different realities
and that can't be the case.
370
00:19:39,011 --> 00:19:42,748
So, on Ethereum, it's the same thing
if you proposed in a way.
So,
371
00:19:42,748 --> 00:19:45,884
if you proposed two different blocks at
the same time, that's a slashable offence.
372
00:19:46,285 --> 00:19:49,655
Or if you attest, in other words,
say here's my view of Ethereum,
373
00:19:49,988 --> 00:19:52,658
but you say they're
two different realities at the same time.
374
00:19:52,658 --> 00:19:55,561
That's a slashable offence.
If you commit a slashable,
375
00:19:56,728 --> 00:19:59,131
the result is the same.
376
00:19:59,131 --> 00:20:00,566
There's an initial penalty.
377
00:20:00,566 --> 00:20:04,236
Today it's 130 seconds of your balance.
So, if you're holding 32e
378
00:20:04,236 --> 00:20:07,239
that's typically the case, you lose 1e.
379
00:20:07,539 --> 00:20:09,942
After that, there's a 36-day period
380
00:20:09,942 --> 00:20:12,945
where you accrue or sorry, incur
381
00:20:13,345 --> 00:20:17,282
these performance penalties, okay.
382
00:20:17,282 --> 00:20:18,984
So, like the one I first mentioned.
383
00:20:18,984 --> 00:20:21,987
In other words,
you're not contributing to,
384
00:20:22,020 --> 00:20:23,822
you're not properly attesting
385
00:20:23,822 --> 00:20:27,993
to Ethereum for 36 days.
Now, here's
a little bit of a complicated part.
386
00:20:27,993 --> 00:20:29,561
The last thing that happens.
387
00:20:29,561 --> 00:20:32,564
And by the way, while this is happening,
you're being exited from the active set.
388
00:20:32,965 --> 00:20:35,968
You're also being booted out the exit.
389
00:20:36,001 --> 00:20:39,071
18 days into that 36 day period,
390
00:20:39,071 --> 00:20:42,441
a proportional slashing multiplier
like this is the dangerous bit.
391
00:20:43,709 --> 00:20:46,445
What happens is Ethereum says
392
00:20:46,445 --> 00:20:49,548
in kind of a colloquial or what
would you say,
393
00:20:49,581 --> 00:20:51,750
kind of like an analogy here.
This obviously isn't literally
394
00:20:51,750 --> 00:20:54,152
what happens, but Ethereum says to itself,
are we being attacked?
395
00:20:55,120 --> 00:20:58,023
And the way that Ethereum assesses
that is, it looks at the proportion
396
00:20:58,023 --> 00:21:01,994
of other validators that have also
committed a slashable offence.
397
00:21:01,994 --> 00:21:06,298
So, let's say 18 days into your 36-day
window, Ethereum
398
00:21:06,298 --> 00:21:10,802
looks 18 days before you committed
your slashable offence, 18 days after.
399
00:21:11,069 --> 00:21:14,072
And it calculates
the percentage based on the state of
400
00:21:14,573 --> 00:21:17,342
other validators
that have committed a slashable offense.
401
00:21:17,342 --> 00:21:20,879
It takes the percentage, let's say it's 5%
and it multiplies it by three.
402
00:21:21,146 --> 00:21:22,481
So, you get 15%.
403
00:21:22,481 --> 00:21:24,983
That's the additional amount of tokens
that are taken away from you
404
00:21:24,983 --> 00:21:25,884
with slashing.
405
00:21:25,884 --> 00:21:27,853
That's the proportional
slashing multiplier.
406
00:21:27,853 --> 00:21:30,622
I know it's a lot,
but this is convoluted.
So
407
00:21:30,622 --> 00:21:34,726
those are the three broad risks
in running a validator.
408
00:21:35,794 --> 00:21:38,263
Obviously, different networks
look different.
409
00:21:38,263 --> 00:21:40,098
Some of them are less punitive.
410
00:21:40,098 --> 00:21:43,702
So, for instance,
I talked about implicit versus explicit.
411
00:21:43,969 --> 00:21:46,071
Some networks don't penalize you.
412
00:21:46,071 --> 00:21:49,174
What they do is jail you, meaning they
take your validator out of the active set.
413
00:21:49,741 --> 00:21:52,377
They make you sit in the penalty box
for a while, and then you can get back in
414
00:21:52,377 --> 00:21:55,714
and start validating again.
There's that opportunity cost
415
00:21:56,114 --> 00:21:59,284
or implicit penalty of being taken out
and not earning rewards.
416
00:21:59,785 --> 00:22:01,320
Anyway,
I'll take a pause. That's a lot. So,
417
00:22:02,354 --> 00:22:04,589
and Ben just to
418
00:22:04,589 --> 00:22:09,394
piggyback off that, how is it
fair to say that slashing events on
419
00:22:09,394 --> 00:22:13,365
Ethereum, at least,
are quite infrequent or uncommon?
420
00:22:13,765 --> 00:22:16,768
How many slashing events typically happen
421
00:22:16,768 --> 00:22:19,771
in a year on Ethereum?
422
00:22:19,905 --> 00:22:23,442
Well, what I can tell you,
I don't have the number like per year,
423
00:22:23,442 --> 00:22:26,445
but I would say, well, roughly,
you know, Beacon Chain has been around
424
00:22:26,611 --> 00:22:29,581
for roughly four years,
launched end of 2020.
425
00:22:29,981 --> 00:22:32,918
I think there's something I have to check,
but it's probably the magnitude
426
00:22:32,918 --> 00:22:35,921
is around 400 slashable offenses.
427
00:22:35,954 --> 00:22:38,590
So, you know, you do
the math, let's say roughly 100 a year
428
00:22:38,590 --> 00:22:41,259
probably skewed
towards the launch of Beacon Chain.
429
00:22:41,259 --> 00:22:45,163
People are figuring things out,
but I take that as a rough guide.
430
00:22:45,163 --> 00:22:46,998
So, to answer your question, George,
431
00:22:48,033 --> 00:22:50,736
not hugely frequent.
432
00:22:50,736 --> 00:22:52,938
I think we'll get into this
maybe more a little bit later.
433
00:22:52,938 --> 00:22:54,873
But I would say that
Ethereum is constantly changing.
434
00:22:54,873 --> 00:22:55,440
And to your point,
435
00:22:55,440 --> 00:22:59,611
which is a great one, you know, Ethereum
as we understand it today, i.e.
436
00:22:59,611 --> 00:23:03,949
post-merge Ethereum has only been around
for two years.
So,
437
00:23:04,683 --> 00:23:07,919
we can set our empirical, expectations
or whatever.
438
00:23:08,286 --> 00:23:10,088
But Ethereum's a changing animal.
439
00:23:10,088 --> 00:23:13,592
So, I kind of just want to highlight
that point I think that was
440
00:23:13,592 --> 00:23:17,229
a great synopsis of the technical risks
associated with staking.
441
00:23:17,562 --> 00:23:20,565
But just to add
one more on the non-technical side,
442
00:23:20,899 --> 00:23:24,102
and that is regulatory uncertainty
as it relates to staking.
443
00:23:24,102 --> 00:23:29,307
So, as it stands today, there's
a bit of an inconsistent global approach
444
00:23:29,307 --> 00:23:33,211
as to how to regulate staking.
So different countries and jurisdictions
445
00:23:33,211 --> 00:23:36,715
are taking varied approaches
to regulating the space.
446
00:23:37,249 --> 00:23:40,519
That creates some challenges for companies
operating across borders
447
00:23:40,952 --> 00:23:44,389
and for investors participating in global
staking pools, right.
448
00:23:45,090 --> 00:23:49,327
There's also an ongoing debate
about whether staking rewards should be
449
00:23:49,327 --> 00:23:53,532
classified as income, capital gains,
or something else entirely.
450
00:23:54,099 --> 00:23:58,236
So, data ambiguity
also affects tax reporting and compliance.
451
00:23:58,970 --> 00:24:02,674
But ultimately, the rapid pace of change
452
00:24:02,674 --> 00:24:06,578
and innovation in crypto usually outpaces
regulatory developments.
So,
453
00:24:06,978 --> 00:24:11,283
this is something that regulators are now
educating themselves on
454
00:24:11,283 --> 00:24:16,254
and introducing new guidelines
for all participants involved in staking.
455
00:24:16,254 --> 00:24:16,588
Yeah.
456
00:24:18,990 --> 00:24:21,426
Ben thanks for that.
457
00:24:21,426 --> 00:24:22,561
You know, great explanation
458
00:24:22,561 --> 00:24:25,564
on all the different technical risks
that relate to staking.
459
00:24:26,765 --> 00:24:29,401
The way I see it is
460
00:24:29,401 --> 00:24:33,772
there are certainly some unique risks
associated with staking, like you
461
00:24:33,772 --> 00:24:38,410
mentioned, slashing,
making sure that, you know, the validators
462
00:24:39,311 --> 00:24:43,715
are in conformance with Ethereum
requirements, the protocol requirements,
463
00:24:44,382 --> 00:24:49,588
so that they always remain on
the most recent canonical chain.
Right.
464
00:24:49,588 --> 00:24:53,925
So that is, absolutely,
you know, a risk to consider.
465
00:24:53,925 --> 00:24:57,596
But a lot of the other risks
that you mentioned around being available,
466
00:24:57,596 --> 00:25:00,599
you know, being, the uptime
that is expected,
467
00:25:00,899 --> 00:25:03,401
those risks are not new.
468
00:25:03,401 --> 00:25:07,105
Those risks are traditional risks
that have existed,
469
00:25:07,105 --> 00:25:10,408
you know, around data centers
and other businesses
470
00:25:10,976 --> 00:25:14,880
and the way when I put on my technology
risk hat.
471
00:25:14,880 --> 00:25:18,750
I've been a technology risk auditor
all my life, when I put on that hat,
472
00:25:19,417 --> 00:25:20,151
these risks have
473
00:25:21,453 --> 00:25:23,655
also traditional ways of
474
00:25:23,655 --> 00:25:26,892
being addressed.
So having a, you know,
business continuity plan in place,
475
00:25:26,892 --> 00:25:30,962
a disaster recovery plan in place,
making sure your infrastructure
476
00:25:32,130 --> 00:25:36,034
is adequate enough
to, you know, let's say,
477
00:25:36,501 --> 00:25:39,304
be able to meet those commitments
478
00:25:39,304 --> 00:25:44,142
of uptime, availability, etc.,
that obviously,
479
00:25:44,376 --> 00:25:47,379
you know, are some of the things
to consider and think about.
480
00:25:47,913 --> 00:25:49,614
But beyond that,
481
00:25:49,614 --> 00:25:52,851
there are also some risks related
to, let's say,
482
00:25:53,151 --> 00:25:56,321
more on the crypto side of it
The key
483
00:25:56,321 --> 00:25:59,324
management, the smart contract, right,
484
00:25:59,758 --> 00:26:02,761
so can you highlight a little bit more on
485
00:26:03,361 --> 00:26:07,365
how relevant those risks are and how are
some of those risks are different
486
00:26:07,365 --> 00:26:11,836
from your existing risks
in the crypto space?
487
00:26:11,836 --> 00:26:13,471
That's great.
488
00:26:13,471 --> 00:26:17,542
You know, and I really like the point too
about just going back for a second,
489
00:26:17,876 --> 00:26:21,780
you know,
there are well known methods to address
490
00:26:21,780 --> 00:26:25,550
some of the risks, like uptime and things
like that.
And, I'm glad you mentioned
491
00:26:25,550 --> 00:26:28,620
key security, because that's something
I think that's often overlooked.
492
00:26:28,653 --> 00:26:30,956
And I think staking is an interesting one.
493
00:26:30,956 --> 00:26:33,458
So, you know,
we're all aware of key security risks.
494
00:26:33,458 --> 00:26:34,259
You hear about,
495
00:26:34,259 --> 00:26:37,829
you know, my key was compromised because
I use a bad app or something like that.
496
00:26:37,829 --> 00:26:39,731
And this is now,
I'm not talking so much about validators.
497
00:26:39,731 --> 00:26:40,832
I'm talking about users.
498
00:26:42,133 --> 00:26:45,136
And staking is kind of interesting
because,
499
00:26:45,837 --> 00:26:48,840
you know, tying back to some of the risks
that I talked about, slashing.
500
00:26:49,441 --> 00:26:52,944
There is a risk of slashing
if you have a compromised validator key
501
00:26:53,945 --> 00:26:58,183
and there's also a risk in terms
of just mismanagement of a backup process.
502
00:26:58,183 --> 00:27:01,186
And I'll come back to that in a second.
But what's interesting is that
503
00:27:02,020 --> 00:27:05,223
with a validator, at least on Ethereum,
and I think a lot of other networks
504
00:27:05,724 --> 00:27:08,026
potentially similar,
505
00:27:08,026 --> 00:27:11,630
it's a different kind of risk if you have
your validator key compromised.
506
00:27:11,796 --> 00:27:15,100
And so, you know, you think about it,
it's like if you were trying
507
00:27:15,100 --> 00:27:18,103
to steal someone's Eth, let's say
508
00:27:18,470 --> 00:27:22,507
stealing from a validator is probably
the last thing you would try to do,
509
00:27:22,741 --> 00:27:25,810
because it's a lot easier to steal,
presumably from someone's EOA
510
00:27:26,011 --> 00:27:29,481
instead of some sort of sketchy.
I don't
know, Efi app or something like that.
511
00:27:29,681 --> 00:27:32,784
And then you have, private signature
and then you can do whatever you want,
512
00:27:33,051 --> 00:27:36,121
whereas, you know, not to say
it will never happen,
513
00:27:36,621 --> 00:27:40,392
but the Eth going from Beacon Chain to,
514
00:27:41,226 --> 00:27:44,195
an EOA externally owned account,
other than
515
00:27:44,195 --> 00:27:47,198
what is specified in the withdrawal
credentials, has never happened,
516
00:27:47,298 --> 00:27:50,268
and I don't suspect it
to.
So, it's kind of interesting.
517
00:27:50,268 --> 00:27:54,406
This key security is still very important,
but the risk is a little bit
518
00:27:54,406 --> 00:27:57,409
different than when you think of
e-security as a user.
519
00:27:57,442 --> 00:28:00,712
The other thing too, I wanted to mention
in terms of backup strategies,
520
00:28:01,012 --> 00:28:04,582
I think I absolutely agree
that there are known solutions
521
00:28:04,582 --> 00:28:07,585
to some of these problems.
The one thing
I would say, though, and just caution,
522
00:28:07,652 --> 00:28:10,689
if you're thinking about maximizing
uptime,
523
00:28:11,523 --> 00:28:15,894
is, you know, some of these slashings
that we've seen
524
00:28:16,428 --> 00:28:19,197
have been related to, operators,
525
00:28:19,197 --> 00:28:22,233
backup systems and the idea is that,
526
00:28:22,600 --> 00:28:25,270
you know, if you have a primary,
let's say you're worried about
527
00:28:26,671 --> 00:28:29,140
your cloud provider going down.
Okay.
528
00:28:29,140 --> 00:28:30,408
And so, you've got, let's say,
529
00:28:30,408 --> 00:28:33,845
I don't know, ABC cloud provider
and then XYZ cloud provider.
530
00:28:33,845 --> 00:28:37,482
And you run your primary on ABC
and you run your backup on XYZ.
531
00:28:38,583 --> 00:28:41,853
What you don't want to happen
is to have those validator keys
532
00:28:41,853 --> 00:28:45,390
running on both clouds at the same time,
because now you're going to commit
533
00:28:45,824 --> 00:28:46,458
a slashable offence.
534
00:28:46,458 --> 00:28:51,596
And so, I think I absolutely agree and all
and I think that, looking at Web2 and,
535
00:28:51,596 --> 00:28:55,400
and some other areas of the tech space
are very informative and important.
536
00:28:55,800 --> 00:28:59,804
But I think that there's this, this layer
of nuance with, with crypto and Web3,
537
00:29:00,338 --> 00:29:03,374
that I think that folks
should just generally be mindful
538
00:29:03,408 --> 00:29:05,643
of in
terms
of risk management and optimizing uptime.
539
00:29:08,446 --> 00:29:11,216
I want to add to that,
540
00:29:11,216 --> 00:29:12,984
you know, at Figment
541
00:29:12,984 --> 00:29:15,987
we have this mantra,
safety over lightness,
542
00:29:16,020 --> 00:29:20,024
and that's actually rooted in exactly
what Ben has been describing.
543
00:29:20,692 --> 00:29:23,328
Earlier
he mentioned that the penalties for
544
00:29:23,328 --> 00:29:28,800
being offline is just like a few bucks,
545
00:29:30,068 --> 00:29:32,937
even if you are off for a whole day,
right.
546
00:29:32,937 --> 00:29:35,406
I'm ignoring, the inactivity leaks
547
00:29:35,406 --> 00:29:38,409
and those kind of situations.
548
00:29:38,443 --> 00:29:40,845
But, so when,
549
00:29:40,845 --> 00:29:43,848
let's say the cloud provider is off,
550
00:29:43,982 --> 00:29:49,454
some might be tempted to go
with having a backup system
551
00:29:49,454 --> 00:29:54,425
that immediately starts your operations
in a different cloud or a different region
552
00:29:55,393 --> 00:29:58,897
to ensure
that the operation is continuing.
But
553
00:30:00,131 --> 00:30:04,402
in a risk adjusted reward type of model
554
00:30:04,936 --> 00:30:09,507
that doesn't justify that,
because the moment that you start doing
555
00:30:09,507 --> 00:30:13,144
double signing,
you will commit a slashable offense.
556
00:30:13,878 --> 00:30:18,149
And so what we do at Figment,
and we really encourage our customers
557
00:30:18,483 --> 00:30:22,253
to think this way is
that it's much better to stay offline
558
00:30:22,720 --> 00:30:26,391
and do not engage in
trying to optimize for uptime,
559
00:30:26,724 --> 00:30:30,628
which is, quite frankly,
usually around 99% or something,
right.
560
00:30:30,695 --> 00:30:34,732
Anyway, so for that extra 1%,
which translates to just a few bucks,
561
00:30:35,033 --> 00:30:38,169
don't try to risk, your full
562
00:30:38,736 --> 00:30:42,040
per validator and commit
a slashable offense.
563
00:30:42,240 --> 00:30:46,411
So, what we do is that we basically
stay offline, we don't do that.
564
00:30:46,978 --> 00:30:51,683
And this is interesting
because sometimes we want to ask that.
565
00:30:51,683 --> 00:30:56,321
Okay, you are offering your solutions
in different regions.
566
00:30:57,121 --> 00:31:01,159
And so,
it is completely feasible for us to do it.
567
00:31:01,159 --> 00:31:03,561
It’s just not logical.
568
00:31:03,561 --> 00:31:05,997
It’s not a risk adjusted
569
00:31:08,366 --> 00:31:11,035
reward in our definition.
570
00:31:11,035 --> 00:31:14,639
And I want to get back to what George says
about regulatory risks.
571
00:31:14,639 --> 00:31:18,076
On one of the things that,
572
00:31:18,810 --> 00:31:22,780
you know,
we take the risks and mitigation of risks
573
00:31:22,780 --> 00:31:26,851
very seriously and that kind of informs
our product strategy
574
00:31:28,019 --> 00:31:30,288
and the way that we approach things.
575
00:31:30,288 --> 00:31:34,893
And one of the tools in our toolkit
is the diversity.
576
00:31:35,493 --> 00:31:38,463
And, for something like regulatory risk,
577
00:31:39,097 --> 00:31:43,301
what we have done with that is
we offered the option to our customers
578
00:31:43,568 --> 00:31:46,571
to have their operations
in their region of choice,
579
00:31:47,138 --> 00:31:50,308
and it is also possible to migrate
from one region to another.
580
00:31:51,042 --> 00:31:54,279
So, this is basically, one of the ways
581
00:31:54,279 --> 00:31:57,282
that we allow our customers
582
00:31:58,049 --> 00:32:01,286
to strategize and to be strategic about
583
00:32:02,353 --> 00:32:05,523
the choices,
so they can mitigate risk.
And that one
584
00:32:05,523 --> 00:32:09,494
was related to regulatory and compliance.
585
00:32:09,494 --> 00:32:11,195
Fantastic advice.
586
00:32:11,195 --> 00:32:15,199
Now, given the risks that you mentioned,
what strategies can stakeholders employ
587
00:32:15,199 --> 00:32:16,034
to minimize?
588
00:32:17,201 --> 00:32:17,602
Great.
589
00:32:17,602 --> 00:32:18,536
Great question.
590
00:32:18,536 --> 00:32:21,539
I think just to start,
I do want to say, and this is going to be
591
00:32:21,572 --> 00:32:23,207
maybe a little bit obvious,
a little bit banal.
592
00:32:23,207 --> 00:32:26,577
So, but I do think understanding
593
00:32:27,278 --> 00:32:30,281
is the prerequisite
for proper risk management.
So,
594
00:32:31,716 --> 00:32:33,785
and again, it does sound kind of obvious,
595
00:32:33,785 --> 00:32:36,788
but I think to some folks, you know,
596
00:32:37,188 --> 00:32:39,724
at least with respect to Ethereum,
it's easy
597
00:32:39,724 --> 00:32:41,526
to think all Ethereum's
been around for a long time.
598
00:32:41,526 --> 00:32:42,560
And like the Ethereum
599
00:32:42,560 --> 00:32:44,729
we know today is the exact same
as when Beacon Chain launched.
600
00:32:44,729 --> 00:32:46,230
That's simply not the case.
601
00:32:46,230 --> 00:32:50,802
You know, again, to just kind of double
down on George's point.
We know today,
602
00:32:51,336 --> 00:32:54,539
you could argue
more or less happened September 2022.
603
00:32:54,839 --> 00:32:56,574
And there have been other forks
since then.
604
00:32:56,574 --> 00:32:59,577
So, the way I think about
it is a bit of a conceptual shift where,
605
00:33:00,211 --> 00:33:03,281
looking from today and going backwards,
the question is how far back
606
00:33:03,281 --> 00:33:06,284
you go before
Ethereum is so fundamentally changed
607
00:33:06,417 --> 00:33:09,420
that the logic is different.
You have to change the way you look at it.
608
00:33:09,721 --> 00:33:13,558
So, getting back on track and questions
about risk management, you know, Reza
609
00:33:13,558 --> 00:33:18,663
talked about the philosophy around
how do you think about earning rewards
610
00:33:18,963 --> 00:33:22,000
and not taking excessive risk
and putting your stake at excessive risk?
611
00:33:22,000 --> 00:33:24,802
I think philosophy
is one of the key things.
612
00:33:24,802 --> 00:33:28,039
If you're a token holder and you're
looking for a staking service provider,
613
00:33:28,406 --> 00:33:32,677
make sure that whichever
staking service provider you use aligns
614
00:33:32,677 --> 00:33:36,447
with your philosophy of risk,
and obviously everyone's risk preferences
615
00:33:36,447 --> 00:33:39,450
will change, will differ.
And you know, people can vary
616
00:33:39,450 --> 00:33:42,420
quite a bit in terms of their appetite
and willingness to accept risk.
617
00:33:42,820 --> 00:33:45,690
But I think philosophy is the first one
that needs to align.
618
00:33:45,690 --> 00:33:47,959
There are also technical
solutions too like there are
619
00:33:49,560 --> 00:33:51,896
programs
that help with slashing protection.
620
00:33:51,896 --> 00:33:55,600
So, if you look at the specs on Ethereum,
you can actually go to the lines
621
00:33:55,600 --> 00:33:58,770
of the specs.
And it's like between 10 to 15 lines that
622
00:33:59,170 --> 00:34:01,773
define what is a slash condition.
623
00:34:01,773 --> 00:34:05,209
So, you know, there are these programs
that are relatively simple.
624
00:34:05,209 --> 00:34:09,147
And basically, it amounts to a database
of what you signed as a validator.
625
00:34:09,414 --> 00:34:10,982
And it can check for you to make sure
626
00:34:10,982 --> 00:34:12,817
that you're
not going to commit a slashable offence.
627
00:34:12,817 --> 00:34:16,320
So that's one thing
that's a technical solution.
628
00:34:16,921 --> 00:34:19,390
But also,
you know, policies and procedures
629
00:34:19,390 --> 00:34:22,827
that kind of dovetail in your philosophy
are also very important.
630
00:34:22,827 --> 00:34:25,830
I think for me,
631
00:34:26,431 --> 00:34:29,067
I don't know if it's necessarily
policy or procedure, but
632
00:34:29,067 --> 00:34:32,103
I guess, the takeaway from the philosophy
is what you don't want to do.
633
00:34:32,103 --> 00:34:36,474
And Reza touched on this.
You don't
if there's a situation on Ethereum
634
00:34:36,474 --> 00:34:39,911
that's abnormal and you know, there's
an activity leak or something's
635
00:34:39,911 --> 00:34:42,914
happening, you don't understand
that the performance is degrading.
636
00:34:43,114 --> 00:34:45,983
What you don't want to do
is a knee jerk reaction to something.
637
00:34:45,983 --> 00:34:50,221
And, you know, migrate validators
or do something drastic
638
00:34:50,822 --> 00:34:55,460
to react and to try and maintain uptime.
It's better to take the loss for, however
639
00:34:55,460 --> 00:34:58,863
many hours, figure out what's going on,
and then react accordingly.
640
00:34:58,863 --> 00:35:03,768
And all of this is based on having a sound
understanding of how the network works.
641
00:35:04,235 --> 00:35:08,639
Okay, so you think about what are the
different ways in which I can be slashed.
642
00:35:09,073 --> 00:35:10,708
Okay. That's the most important thing.
643
00:35:12,076 --> 00:35:14,212
Customer
state is of paramount importance.
644
00:35:14,212 --> 00:35:17,815
And then everything else, you can kind of
prioritize according to that.
645
00:35:22,587 --> 00:35:24,422
I want to add to
646
00:35:24,422 --> 00:35:27,458
what Ben says and, regarding,
647
00:35:28,059 --> 00:35:32,930
some of the penalties
and some of the risks that people take is
648
00:35:33,131 --> 00:35:36,901
based on the, you know,
definitions of the protocol itself.
649
00:35:36,901 --> 00:35:42,273
It differs widely from one,
POS network to another.
650
00:35:42,840 --> 00:35:46,511
And, but there are also some, risks
651
00:35:46,511 --> 00:35:49,514
that are more subtle, but they can
652
00:35:51,082 --> 00:35:52,783
be very important.
653
00:35:52,783 --> 00:35:56,721
And again, understanding the risks as Ben
said is the key here.
654
00:35:57,155 --> 00:36:02,326
And one of the things that, you know,
for instance, we really think in
655
00:36:02,326 --> 00:36:05,329
our research is just that, reward,
656
00:36:05,463 --> 00:36:08,699
strategies, how we implement
657
00:36:09,967 --> 00:36:15,006
our solution
and how are we basically safeguarding our
658
00:36:16,674 --> 00:36:19,710
customer's assets,
given the rewards and the risks?
659
00:36:19,710 --> 00:36:23,314
And one of the things that we are very
conscious of is, for example,
660
00:36:24,782 --> 00:36:25,716
sometimes
661
00:36:25,716 --> 00:36:28,920
what is happening is that some operators
662
00:36:28,920 --> 00:36:33,424
might decide to take the open source
software for a component.
663
00:36:33,424 --> 00:36:37,128
Let's say a client may post,
in case of Ethereum,
664
00:36:37,562 --> 00:36:41,199
and they might actually start modifying it
665
00:36:41,766 --> 00:36:45,636
highly to just optimize it
for certain metrics.
It could be rewards,
666
00:36:45,636 --> 00:36:48,139
it could be performance,
it could be throughput.
667
00:36:48,139 --> 00:36:51,609
And it works great until it doesn't work
great anymore.
668
00:36:51,609 --> 00:36:54,612
Then let's say there is vulnerability
669
00:36:55,179 --> 00:36:59,116
network wide
or above in the original, source code.
670
00:36:59,750 --> 00:37:01,052
And now this is a challenge.
671
00:37:01,052 --> 00:37:07,291
This is a bad situation
because, the open source community
672
00:37:08,593 --> 00:37:11,729
test things and they offer things.
Then they are battle tested
673
00:37:12,396 --> 00:37:17,401
after many months of, you know,
going through rigorous, you know, tests
674
00:37:17,435 --> 00:37:21,806
through different situations,
and they offer a hotfix.
675
00:37:22,373 --> 00:37:24,242
And now this operator
676
00:37:25,843 --> 00:37:27,411
has this.
677
00:37:27,411 --> 00:37:31,048
It is possible in all likelihood
678
00:37:31,048 --> 00:37:34,051
that they cannot
just with a quick swap and,
679
00:37:34,418 --> 00:37:37,888
you know, benefit from this protection
against that vulnerability.
680
00:37:38,122 --> 00:37:42,994
Now they have to quickly modify
this new hotfix
681
00:37:42,994 --> 00:37:48,299
and try to operationalize it.
So,
they are essentially swapping it.
682
00:37:48,299 --> 00:37:51,302
Battle test
that software with a thinly tested one.
683
00:37:51,469 --> 00:37:55,172
And that actually introduces settlement
risk at the operator level.
684
00:37:55,172 --> 00:37:58,743
It has nothing to do with the network,
but it opens up for
685
00:38:00,244 --> 00:38:02,847
some sort of slashable offence
686
00:38:02,847 --> 00:38:05,850
or some other penalties in that sort.
687
00:38:06,150 --> 00:38:09,287
And we take these kind of risks
into consideration
688
00:38:09,320 --> 00:38:12,323
when we are making a decision
689
00:38:12,390 --> 00:38:15,393
about how we operationalize our staking.
690
00:38:17,061 --> 00:38:17,461
Yeah.
691
00:38:17,461 --> 00:38:19,964
Thank you Reza and Ben.
692
00:38:19,964 --> 00:38:22,333
You know, the way I think about risk.
693
00:38:22,333 --> 00:38:26,170
Because we work with clients that are both
694
00:38:26,470 --> 00:38:29,340
you know, node operators
such as yourselves,
695
00:38:29,340 --> 00:38:32,610
as well as institutions
that are looking to get involved
696
00:38:32,610 --> 00:38:36,580
in staking and,
you know, even some of the asset managers
697
00:38:36,580 --> 00:38:41,619
that, let's say, are looking to launch
or have launched staked Ethereum ETFs,
698
00:38:42,620 --> 00:38:44,388
there is a need
699
00:38:44,388 --> 00:38:47,458
for those institutional clients
to understand
700
00:38:47,858 --> 00:38:50,661
these risks as they're
conducting their due diligence.
701
00:38:50,661 --> 00:38:54,465
And one of the challenges that we faced
as we were doing
702
00:38:54,465 --> 00:38:58,002
some of this kind of work
for a lot of our clients, was
703
00:39:01,072 --> 00:39:02,907
you know, the existing
704
00:39:02,907 --> 00:39:07,311
SOC1 SOC2 attestations
that node operators had
705
00:39:08,145 --> 00:39:12,583
was not sufficient
for us to confirm that. Yes.
706
00:39:12,950 --> 00:39:18,022
You know, the risks around slashing
are adequately addressed by this node
707
00:39:18,022 --> 00:39:19,590
operator.
So, we would
708
00:39:19,590 --> 00:39:22,960
typically go into a lot more detail
in asking those questions
709
00:39:24,161 --> 00:39:27,798
and having a local anti-slashing
710
00:39:27,798 --> 00:39:31,402
database as well as how do you manage
doppelganger detection.
711
00:39:31,769 --> 00:39:34,271
Do you have DVT implementation, etc.
712
00:39:34,271 --> 00:39:36,240
Like,
we would ask a lot of those questions
713
00:39:36,240 --> 00:39:41,512
on top of just reviewing
like a SOC2 report or a SOC1 report.
714
00:39:42,113 --> 00:39:45,116
And I feel like for institutions,
715
00:39:45,783 --> 00:39:48,786
it is very hard for them
716
00:39:48,953 --> 00:39:52,690
to really get comfortable,
717
00:39:53,624 --> 00:39:56,627
even if we are coming in
and doing an independent,
718
00:39:56,627 --> 00:40:01,332
doing an assessment, like without having
a proper standard around these things
719
00:40:01,332 --> 00:40:05,336
and these, risk mitigation
requirements, it's very difficult for them
720
00:40:05,703 --> 00:40:10,775
to get comfortable on the infrastructure
and the controls that may exist to address
721
00:40:10,775 --> 00:40:15,913
those unique risks that are on slashing.
It is very technical, right. So,
722
00:40:16,914 --> 00:40:19,850
one of the areas that
723
00:40:19,850 --> 00:40:22,853
I'm going to focus
more on is the institutional side because,
724
00:40:23,754 --> 00:40:26,957
you know, the node operators,
they understand there is their day to day.
725
00:40:27,324 --> 00:40:31,595
They have people like
you guys who can dive deep into,
726
00:40:31,595 --> 00:40:34,698
you know, the repo
and have the whole history around that.
727
00:40:35,199 --> 00:40:39,470
But for institutions, as they are
looking to address these risks.
728
00:40:39,470 --> 00:40:42,339
As they look to get into staking,
729
00:40:42,339 --> 00:40:44,942
is really to look at some of the standards
730
00:40:44,942 --> 00:40:49,280
that are being developed around staking,
so similar
731
00:40:49,280 --> 00:40:53,717
to how you have your SOC1 and SOC2
for cloud service providers.
732
00:40:53,717 --> 00:40:56,954
There are, you know, there’s a CSA star,
733
00:40:57,521 --> 00:41:00,624
certification as well,
which is by the Cloud Security Alliance.
734
00:41:01,592 --> 00:41:06,831
Staking now also has a standard
that's been developed by,
735
00:41:07,231 --> 00:41:10,801
you know, the Liquid Collective
and the Illumio folks, which is really
736
00:41:11,068 --> 00:41:16,440
a lot of more mature node operators
coming together and understanding
737
00:41:16,440 --> 00:41:20,444
that one, there is a need
for decentralization around staking.
738
00:41:20,444 --> 00:41:24,415
And second is
how do we make this infrastructure
739
00:41:24,415 --> 00:41:28,552
more mature because when their clients
are reaching out to them
740
00:41:28,819 --> 00:41:32,089
and, you know, through us
most times, we’re asking
741
00:41:32,456 --> 00:41:37,094
a lot of the more technical questions
that go beyond SOC1 SOC2.
742
00:41:37,094 --> 00:41:41,732
So NORS switches
that node operator risk standard
743
00:41:42,600 --> 00:41:45,302
is now launched.
744
00:41:45,302 --> 00:41:46,337
It was actually launched.
745
00:41:46,337 --> 00:41:49,106
We're recording on October third.
746
00:41:49,106 --> 00:41:49,907
It was launched on
747
00:41:51,542 --> 00:41:54,311
September 30th I believe,
748
00:41:54,311 --> 00:41:58,649
which really helps institutions
get a lot more comfort on
749
00:41:58,983 --> 00:42:02,186
if a node operator is NORS certified
750
00:42:02,753 --> 00:42:06,957
that they have been through
an independent audit
751
00:42:07,291 --> 00:42:10,160
by qualified assessors,
752
00:42:10,160 --> 00:42:12,997
such as, you know, KPMG,
753
00:42:12,997 --> 00:42:18,002
that have come in, asked all the more
technical question, done independent
754
00:42:18,002 --> 00:42:21,205
testing around it and are now able to just
755
00:42:21,605 --> 00:42:24,542
take that NORS certification and
756
00:42:24,542 --> 00:42:26,644
you know, again, KPMG is not the one
757
00:42:26,644 --> 00:42:29,647
that certifies for NORS.
We just do the independent audit.
758
00:42:29,914 --> 00:42:33,918
But the liquid collective
is the one or the NORS
759
00:42:34,118 --> 00:42:38,122
Inc is the one that actually certifies
based on NORS standard. So
760
00:42:39,723 --> 00:42:43,928
the institutions can be rest assured
that if they are looking to work
761
00:42:43,928 --> 00:42:47,798
with an institutional staking provider
or node operator,
762
00:42:48,465 --> 00:42:51,969
that is NORS certified that they have gone
763
00:42:51,969 --> 00:42:54,972
through independent
audit and attestation work,
764
00:42:55,506 --> 00:42:56,941
to make sure that they have relevant
765
00:42:56,941 --> 00:43:00,244
controls in place and they don't
necessarily need to understand
766
00:43:00,945 --> 00:43:05,115
maybe the last 30 minutes of our
conversation in all technical details
767
00:43:05,349 --> 00:43:09,086
similar to how they would not
go into that level of detail
768
00:43:09,086 --> 00:43:11,589
when they're reviewing a SOC.
1 or SOC2 report,
769
00:43:11,589 --> 00:43:14,525
but because they're relying on the experts
to come in and do the audits.
770
00:43:14,525 --> 00:43:18,829
So, I want to highlight, you know, again,
from a risk standpoint, yes,
771
00:43:18,829 --> 00:43:23,901
there are risks that you guys, as node
operators, really need to mitigate.
772
00:43:23,901 --> 00:43:26,036
You need to have those controls in place.
773
00:43:26,036 --> 00:43:29,540
But from the institutional side
as they look to get into
774
00:43:29,540 --> 00:43:32,743
more institutional, in like staking
775
00:43:32,743 --> 00:43:35,980
and offering, let's say, ETPs around it.
776
00:43:37,715 --> 00:43:40,718
They don't need to necessarily
go through all of those
777
00:43:40,751 --> 00:43:46,290
technical questions as long as the staking
provider is NORS certified.
778
00:43:46,290 --> 00:43:49,827
And I would highly encourage,
you know, every
779
00:43:50,461 --> 00:43:53,831
staking operator
that is, maybe listening to this podcast,
780
00:43:54,732 --> 00:43:59,637
to look at NORS as a standard
and as a foundational level of capability
781
00:44:00,070 --> 00:44:03,540
that they would need to have in place
if they are looking to work
782
00:44:03,540 --> 00:44:07,978
with institutions, because a
standard is nothing unless it's adopted.
783
00:44:08,612 --> 00:44:11,215
There's some excellent points
on risk mitigation
784
00:44:11,215 --> 00:44:14,952
and just to round us out on this piece
here, I just want to add
785
00:44:15,252 --> 00:44:18,122
one other risk mitigation consideration
786
00:44:18,122 --> 00:44:21,759
here, is the emergence
of specialized insurance products
787
00:44:21,925 --> 00:44:26,330
that are designed to protect those who
participate in staking activities.
788
00:44:26,830 --> 00:44:30,768
So there are some providers out there
who provide these specialized
789
00:44:30,768 --> 00:44:31,669
insurance products.
790
00:44:31,669 --> 00:44:35,773
And some of the coverage types
include slashing protection.
791
00:44:35,973 --> 00:44:39,943
So that covers losses due to validator
mis-behaviour and technical failures.
792
00:44:40,310 --> 00:44:42,646
As Ben and Reza alluded to earlier,
793
00:44:42,646 --> 00:44:46,083
there's also coverage against smart
contract failure that protects against
794
00:44:46,083 --> 00:44:49,420
losses caused by bugs or vulnerabilities
at smart contracts
795
00:44:50,020 --> 00:44:52,456
that govern staking protocols,
and then finally,
796
00:44:52,456 --> 00:44:56,393
validator downtime as well,
which Ben and Reza also alluded to.
797
00:44:57,494 --> 00:44:58,362
And so, I think
798
00:44:58,362 --> 00:45:02,433
the advent of an extra layer of protection
799
00:45:02,433 --> 00:45:06,570
can help bridge that gap between TradFi
and the world of crypto.
800
00:45:08,706 --> 00:45:09,873
Really glad you brought that
801
00:45:09,873 --> 00:45:12,876
up, George, because I know,
802
00:45:12,976 --> 00:45:17,548
when I went for the launch
event of NORS, earlier this week,
803
00:45:17,981 --> 00:45:23,187
we did have, you know,
quite a few different insurance providers,
804
00:45:23,187 --> 00:45:27,424
even the traditional insurance providers
that were there to understand
805
00:45:27,558 --> 00:45:31,829
how institutional staking
operators are managing their risks.
806
00:45:31,829 --> 00:45:36,233
And, you know, they traditionally relied
on certain standards to underwrite
807
00:45:37,501 --> 00:45:41,338
the policies etc.
And it was good to see a lot of those
808
00:45:41,338 --> 00:45:44,875
insurance
providers in presence, at the event
809
00:45:44,875 --> 00:45:47,878
because they were also curious
to understand,
810
00:45:48,545 --> 00:45:51,749
again, they also don't want to go into
that level of technical details.
811
00:45:51,749 --> 00:45:55,119
So, they want to rely on something,
like a standard in place,
812
00:45:55,986 --> 00:45:57,521
to be able to underwrite.
813
00:45:57,521 --> 00:46:00,390
Fantastic gents.
Thank you all.
814
00:46:00,390 --> 00:46:01,759
Now let's move on to a newer
815
00:46:01,759 --> 00:46:05,229
topic and a concept in the staking world,
which is re-staking.
816
00:46:05,496 --> 00:46:08,799
Can you explain what re-staking
is and how exactly it works?
817
00:46:09,900 --> 00:46:11,535
Absolutely.
818
00:46:11,535 --> 00:46:13,570
so again, from a high level,
819
00:46:13,570 --> 00:46:16,573
Re-staking is actually fairly simple.
820
00:46:16,840 --> 00:46:19,843
At least on the, cover.
821
00:46:20,010 --> 00:46:22,146
So re-staking is about securing
822
00:46:22,146 --> 00:46:25,182
more than one protocol
with the same state.
Okay.
823
00:46:25,215 --> 00:46:29,019
Now, I think there's been a lot of noise
about re-staking lately
824
00:46:29,453 --> 00:46:31,321
with the launch of Eigen layer.
825
00:46:31,321 --> 00:46:34,291
So basically we're seeing re-staking
on Ethereum, which is very exciting.
826
00:46:34,291 --> 00:46:38,128
But for folks that are a little more
in the crypto space, in the Web3 space,
827
00:46:38,529 --> 00:46:39,930
this concept is not new.
828
00:46:39,930 --> 00:46:42,933
So, if you think about chains
like Polkadot, like cosmos SDK change,
829
00:46:43,200 --> 00:46:46,470
if you've heard of terms like replicated
security, shared security,
830
00:46:46,870 --> 00:46:49,873
it's the same concept.
So, you know,
831
00:46:50,040 --> 00:46:53,043
going back to the kind of basic,
832
00:46:53,877 --> 00:46:56,880
definition or framework
I had for understanding staking,
833
00:46:57,247 --> 00:47:01,451
the idea is the same stake is going
to be used for additional protocols.
834
00:47:02,553 --> 00:47:05,923
That does mean that I'll have to run
additional software, additional programs.
835
00:47:05,923 --> 00:47:08,692
So, you know,
I might want to secure Ethereum,
836
00:47:08,692 --> 00:47:10,260
but then the stake that I have
837
00:47:10,260 --> 00:47:13,230
that's allocated to Ethereum,
I might also want to use that
838
00:47:13,297 --> 00:47:15,499
to secure another protocol,
which would mean
839
00:47:15,499 --> 00:47:19,002
I have to run additional software
on that protocol.
840
00:47:19,536 --> 00:47:22,639
But the benefit for me
is that I don't have to go and find,
841
00:47:22,639 --> 00:47:26,243
let's say,
the equivalent of another amount of 32ft.
842
00:47:26,977 --> 00:47:31,381
So in other words, it's kind of like,
an efficient way to use your stake.
843
00:47:31,381 --> 00:47:33,350
You can kind of get multiple turns.
844
00:47:33,350 --> 00:47:35,319
A lot depends on the implementation.
845
00:47:35,319 --> 00:47:38,488
It doesn't always work so cleanly,
but that's generally the idea of restating
846
00:47:38,822 --> 00:47:42,259
securing multiple protocols
with the same state.
Awesome.
847
00:47:42,626 --> 00:47:44,528
And it sounds like a great way
to maximize returns,
848
00:47:44,528 --> 00:47:47,965
but any potential risks
or drawbacks associated with re-staking?
849
00:47:49,132 --> 00:47:51,034
Yeah, that's a great question.
850
00:47:51,034 --> 00:47:52,769
So yes, there are risks.
851
00:47:52,769 --> 00:47:55,906
I think any time you engage
across crypto or Web3,
852
00:47:56,173 --> 00:47:59,643
you touch almost anything,
you're going to incur some risks.
853
00:47:59,643 --> 00:48:02,613
So, you know, if you're depositing
your tokens into a smart contract,
854
00:48:02,779 --> 00:48:06,183
there's a risk there.
Now, generally
speaking, users
855
00:48:06,183 --> 00:48:09,152
certainly on Ethereum have
856
00:48:09,553 --> 00:48:11,455
become comfortable with smart contract
risks.
857
00:48:11,455 --> 00:48:13,257
There are ways to mitigate that.
858
00:48:13,257 --> 00:48:15,692
They can look at the smart contract
itself.
859
00:48:15,692 --> 00:48:17,728
In other words verify in the code.
860
00:48:17,728 --> 00:48:20,731
You can look at audits for smart contracts
861
00:48:20,797 --> 00:48:24,201
as a really rough kind of rule,
I wouldn't rely on this too much, but
862
00:48:24,201 --> 00:48:25,535
generally speaking,
863
00:48:25,535 --> 00:48:27,905
you know, if a contract has been around
for a long time,
864
00:48:27,905 --> 00:48:31,241
as Reza mentioned, kind of battle tested,
then used a lot and there have been
865
00:48:31,241 --> 00:48:34,244
no issues with it,
that should give you
some sort of reassurance.
866
00:48:34,544 --> 00:48:36,847
I'd actually use
this more in the opposite sense.
867
00:48:37,848 --> 00:48:38,982
I would not trust
868
00:48:38,982 --> 00:48:42,486
a new smart contract with no audits
ever been used, put it that way.
869
00:48:43,387 --> 00:48:45,022
So there's smart contract risk,
870
00:48:45,022 --> 00:48:48,692
but I think the big risk for folks
to think about is that, you know,
871
00:48:48,926 --> 00:48:52,863
effectively, you're opting in
to securing additional protocols.
So,
872
00:48:52,863 --> 00:48:57,000
if you think about this, as imagine that,
you know, someone replicated a bunch
873
00:48:57,000 --> 00:49:00,437
of versions of Ethereum on Eigen layer
and you just opted into every one of them.
874
00:49:01,238 --> 00:49:03,540
The slashing risk,
you're also multiplying.
875
00:49:03,540 --> 00:49:05,442
And you have to make certain assumptions
about the scenario.
876
00:49:05,442 --> 00:49:08,679
Like is there any tie back to Ethereum,
in which case
877
00:49:08,912 --> 00:49:11,915
you could have correlated events,
which would be a problem?
878
00:49:12,482 --> 00:49:15,552
And the other kind of nuance here
is that as of right
879
00:49:15,552 --> 00:49:19,456
now, there's no slashing on Eigen layer,
but that is coming, okay.
880
00:49:19,456 --> 00:49:23,460
So, we could do a whole podcast
on the history of Eigen layer.
881
00:49:23,727 --> 00:49:25,395
It's been a little long
in the tooth, to be frank.
882
00:49:26,463 --> 00:49:29,132
But slashing
is coming, and that's something that folks
883
00:49:29,132 --> 00:49:32,135
that are engaged with Eigen layer
today will need to
884
00:49:32,836 --> 00:49:36,506
take into account and should watch
what the slashing penalties look like
885
00:49:36,873 --> 00:49:38,008
and what they've opted into.
886
00:49:38,008 --> 00:49:41,144
Do they want to stay securing
those additional protocols,
887
00:49:41,144 --> 00:49:44,581
or do they want to rethink things
as the penalties become more apparent?
888
00:49:44,781 --> 00:49:47,451
There are also other risks,
but I think those are probably
889
00:49:47,451 --> 00:49:49,486
the big ones
that folks need to kind of grapple with.
890
00:49:49,486 --> 00:49:52,489
They're thinking about risk staking.
891
00:49:53,457 --> 00:49:55,292
Now, I want to go a bit off topic,
892
00:49:55,292 --> 00:49:58,261
if it is okay?
893
00:49:58,261 --> 00:49:59,896
One thing that really excites me
894
00:49:59,896 --> 00:50:03,834
about staking is, of course,
895
00:50:04,501 --> 00:50:09,706
you know, Ethereum,
at the source of security
896
00:50:09,840 --> 00:50:13,043
is basically lending security
to other networks.
897
00:50:13,910 --> 00:50:18,248
But also, you know, thinking
about scalability solutions, right?
898
00:50:18,248 --> 00:50:23,420
It's very expensive to build on layer
one on Ethereum at this point.
899
00:50:23,887 --> 00:50:28,425
So, you know, going off
Eigen layer and building on top of
900
00:50:28,425 --> 00:50:32,162
that could be one way,
but for a different reason. But,
901
00:50:34,664 --> 00:50:34,965
we were
902
00:50:34,965 --> 00:50:38,035
talking about the evolving risk
and how the network is actually evolving.
903
00:50:38,769 --> 00:50:41,038
There are lots of, work
904
00:50:41,038 --> 00:50:44,041
that is happening on the layer
twos, the podium.
905
00:50:45,308 --> 00:50:48,211
We see that, you know, there are
906
00:50:48,211 --> 00:50:52,883
massive developments on shared sequences
and, you know, talks about shared
907
00:50:52,949 --> 00:50:58,455
liquidity and peak confirmations
based rollups and things of that sort
908
00:50:58,722 --> 00:51:03,827
that we are going to see
that it is going to
909
00:51:05,429 --> 00:51:08,298
help with the adoption
910
00:51:08,298 --> 00:51:11,368
of building a different solutions
on Ethereum.
911
00:51:11,368 --> 00:51:15,205
Maybe not on the
layer one,
but on layer two at the lower price,
912
00:51:15,205 --> 00:51:18,208
but benefit from the finality,
913
00:51:18,842 --> 00:51:20,077
of the layer one.
914
00:51:20,077 --> 00:51:22,245
So Ethereum is doing two things.
915
00:51:22,245 --> 00:51:25,248
Then is security. Three is re-staking,
916
00:51:25,482 --> 00:51:28,418
offering finality to the, L2.
917
00:51:28,418 --> 00:51:32,823
So, as we can see, it is becoming more
prominent in the ecosystem
918
00:51:34,491 --> 00:51:35,725
to basically go to the next
919
00:51:35,725 --> 00:51:38,728
phase of the adoption
and in the adoption curve.
Yeah.
920
00:51:38,795 --> 00:51:42,399
Thanks, Ben and Reza,
those are great insights, not only on
921
00:51:42,399 --> 00:51:44,968
some of the risks
associated with re-staking,
922
00:51:44,968 --> 00:51:47,737
but also strategies to help
mitigate those risks.
923
00:51:47,737 --> 00:51:49,539
And Reza, I appreciate you
924
00:51:49,539 --> 00:51:53,410
highlighting a few of the aspects
of re-staking that really excite you.
925
00:51:53,643 --> 00:51:56,546
Unfortunately,
we have hit the end of today's episode.
926
00:51:56,546 --> 00:52:00,951
So once again, thank you, Ben and Reza
for joining us.
And to my resident
927
00:52:00,951 --> 00:52:04,788
co-hosts, Kunal and George, thank you
for helping us stick handle through
928
00:52:04,788 --> 00:52:09,893
another episode of KPMG in Canada's
state of digital assets podcast series.
929
00:52:10,127 --> 00:52:12,829
Until next time,
I'm Adam Rodricks. Bye for now.
