►
From YouTube: Devcon VI Bogotá | Mild Flowers stage - Day 1
Description
Official livestream from Devcon VI Bogotá.
For a decentralized version of the steam, visit: https://live.devcon.org
Devcon is an intensive introduction for new Ethereum explorers, a global family reunion for those already a part of our ecosystem, and a source of energy and creativity for all.
Agenda 👉 https://devcon.org/
Follow us on Twitter 👉 https://twitter.com/EFDevcon
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
B
B
B
C
C
C
E
You
ever
need
us
and
welcome
everybody
how's
everyone
doing
today,
nice,
all
right,
I'm,
Jacob,
montomski,
I'm,
a
developer
on
the
BLS
wallet
project,
and
here
with
me
today-
is
James
Zacky,
who
is
our
Project
Lead
and
we're
going
to
talk
about
BLS
wallet.
E
We're
then
going
to
cover
where
BLS
wallet
is
today
with
some
examples
and
some
of
the
features
we
have
built
in
and
then
we're
going
to
cover
where
we're
going
next
with
the
project.
And
finally,
we
should
have
ample
time
for
questions.
E
Of
it
off
a
little,
that's:
okay,
we're
scattered
all
across
the
globe,
we're
part
of
the
privacy
and
scaling
Explorations
Group,
which
is
a
subgroup
of
the
ethereum
foundation.
We
work
mainly
with
zero
knowledge,
proofs
and
layer,
skit
layer,
2
scaling
technology.
E
So
some
of
the
outcomes
we
want
to
try
to
reach
with
our
project
and
the
primary
one
are
North
Star
or
here
in
the
southern
hemisphere
the
Southern
Cross
is
going
to
be
reduced,
the
the
cost
of
L2
transactions,
primarily
by
reducing
the
amount
of
data
that
is
rolled
up
into
l1s
by
reducing
transaction
size.
E
Currently,
with
some
initial
numbers,
which
are
a
little
difficult
to
see
right
now,
we've
essentially
simulated
running
150
erc20
transfers
both
regularly
normally
on
a
roll-up
as
well
as
bundling
them
all
together
into
a
single
L2
transaction
using
BLS
wallet
and
we've
gotten
it
down
the
transaction
data
size
by
about
a
quarter,
we're
hoping
that
we
can
go
even
further
than
that.
E
We
still
need
to
measure
the
impact
that
we're
going
to
have
on
layer,
one
gas
costs
to
see
how
the
transactions
are
actually
going
to
be
reduced,
but
our
team
likes
to
limbo
and
we
want
to
see
how
low
can
we
go
with
using
some
things
involving
address
books
as
well
as
some
other
indexing
things
to
reduce
that
call
data
even
lower
than
where
it's
at
we'll
get
into
how
we
reduce
that
size
in
a
moment.
E
So
another
outcome
we're
looking
for,
is
to
be
able
to
improve
wallets
one
of
the
features
with
that
is
going
to
be
account
recovery.
Sometimes,
people
talk
about
a
social
recovery,
so
if
your
private
keys
are
compromised,
is
there
a
way
you
can
swap
to
a
more
secure
set
of
private
keys
and
what
kind
of
features,
functionalities
and
security
that
will
enable?
And
then
we
also
want
to
have
upgradable
functionality
for
wallets.
E
And,
finally,
we
want
to
make
d-apps
a
lot
easier
to
use,
and
so
part
of
that
is
by
having
a
baked
in
multi-call
or
we
call
it
multi-actions
where
you
can
take
multiple
transactions
and
put
them
into
one
and
then
also
having
sponsored
transactions
where
the
user
does
not
have
to
pay
gas
on
their
end
and
the
d-app
sponsors
it
instead.
So
that
way,
when
users
first
come
in
to
try
at
the
app
for
the
first
time,
they
don't
have
to
go,
stay
tuned
exchange
to
buy
ethereum,
so
they
can
pay
gas
for
transactions.
E
So,
to
start
off
we're
going
to
cover
BLS
signatures
and
aggregations
at
kind
of
a
high
level.
Bls
stands
for
bone
Lin
chacham
is
a
pairing
cryptography,
based
signature
scheme
used
in
the
ethereum
consensus,
layer,
zcash
and
the
number
of
other
projects.
It
is
deterministic
for
a
given
public
key
and
message.
E
Validators
currently
are
using
BLS
signatures,
specifically
on
the
bls-12381
curve,
two
signed
messages
on
the
consensus
layer
and
then
inside
of
the
evm
execution
layer.
We
have
access
to
the
bn254
curve
via
eip197
that
allows
us
to
which
we
use
in
BLS
wallet
for
both
signing
and
then
verifying
on
train
the
transactions,
we're
hoping
in
the
future
via
a
newer
EIP
that
we
will
be
able
to
actually
move
to
the
beacon
chain
curve
for
more
security
and
for
better
access
to
Frameworks.
E
E
So
normally
with
the
signature
space
you'd
have
taking
up,
we
can
shrink
it
into
just
one,
and
this
is
really
good
for
reducing
the
data
that
we
roll
up
into
an
L1,
because
normally,
when
a
rollup
goes
in,
it
takes
all
the
transaction
data
as
well
as
the
signatures
for
each
of
those
transactions,
specifically
the
RS
and
V
components
of
that
signature.
E
E
E
We're
then
going
to
in
our
case,
though,
have
a
set
of
user
operations
that
we
forward
to
an
aggregator
service
which
is
going
to
take
many
to
separate
operations
and
merge
them
all
together
into
one
and
submit
them
to
an
L2
node,
which
then
will
execute
against
our
contracts
for
the
verification
of
the
signatures
and
then,
through
the
smart
contract
wallet
to
dive
into
that
a
little
bit
more
at
a
high
level.
E
E
The
bundler
will
aggregator
will
take
that
set
of
transactions
and
we'll
submit
them
into
the
layer,
2
evm,
where
we
can
do
some
work
with
expansion
to
expand
the
call
data
parameters
into
more
Advanced
or
more
verbose
data.
We
do
the
BLS
signature,
verification
across
those
and
then
finally,
for
each
of
those
operations
and
actions,
we
submit
it
to
the
actual
contract
wallets
and
that
is
then
executed
against
the
actual
underlying
DF
code.
E
So
this
is
a
library
that
our
teammate
Android
helped
write.
If
you
want
to
try
it
out,
you
can
npm
install
BLS,
wallets
Dash.
Clients
still
keeps
in
that
edge
of
that
stage
in
there
we're
going
to
have
a
bundle
that
we're
generating
and
the
wallet's
going
to
sign
it.
That
operation
is
going
to
have
a
nonce
which
is
going
to
be
the
current
wallet
nonce,
for
if
the
wallet
hasn't
been
created
yet
and
it's
going
to
be
lazily
created
it'll
just
be
zero.
E
We
then
have
an
array
of
actions
where
those
actions
are
Atomic.
So
if
any
one
of
these
actions
were
to
fail,
then
they
all
would
fail.
Inside
of
that,
you
can
specify
an
F
value
as
part
of
that
the
contractor
targeting
and
then
finally,
the
encoded
function
that
you'll
send
over.
E
Foreign
using
building
on
top
of
this
we've
built
a
prototype
browser
extension
wallet,
called
quill
and
fast
cool,
called
quill
with
Andrew
and
katuk,
and.
E
And
as
you
can
see
here
in
an
example,
we
have
a
standard
transaction
confirmation
which
contains
three
actions
inside
of
it,
one
of
them
in
the
middle
being
an
approved.
So
instead
of
a
user
having
to
go
in
and
separately
run
the
transaction
for,
approve
and
say,
transfer
and
something
else,
we
can
do
it
all
in
one
and
have
just
one
confirmation
dialogue
pop
up
to
them.
E
E
But
in
the
middle
we're
injecting
in
this
top
Center
portion
the
aggregator
an
aggregator
proxy
which
essentially
is
taking
those
operations,
we
would
normally
submit
to
an
aggregator
and
is
instead
sending
them
to
it
where
it
qualifies
to
see
if
they're,
if
they
can
be,
you
funded
for
free
gas,
basically,
and
so
then,
that
aggregator
proxy
will
add
that
payment
bundle
in
on
in
there
and
then
submit
it
to
the
normal
aggregator,
which
requires
a
fee,
and
this
allows
for
us
to
have
those
gasless
transactions.
E
Our
teammate
John
has
built
a
very
cool
demo
using
scaffoldeth
for
the
scaffoldeth
community,
which
is
a
single
pool.
Dex
and,
as
you
can
see
here,
it's
a
just
single
pool
decks
with
a
swap.
It
does
use
the
multi-action
as
well
to
do
the
approve
and
the
swap
inside
of
it,
and
then
it
all
runs
inside
of
the
browser
with
no
need
for
like
upfront
gas,
because
the
aggregator
proxy
is
going
to
subsidize
it,
and
so
that
allows
for
free
transaction.
You
can
find
out
more
at
this.
E
We're
also
looking
into
doing
this
directly
via
a
contract.
The
way
the
aggregator
currently
works
is
when
it
receives
a
bundle.
It's
going
to
actually
introspect
and
look
at
whether,
when
it
stimulates
executing
that
transaction,
if
it
gets
paid
either
in
F,
or
we
also
allow
erc20
tokens
if
it
sees
that
it
happens,
it
will
include
it
in
the
bundle
it's
going
to
submit
to
layer
2..
E
E
E
We
sold
more
research
to
be
done
to
figure
this
out,
but
we
believe
it
should
be
pretty
feasible
and
possible
to
do
all
right
and
now
I'm
going
to
hand
things
over
to
my
teammate
James
James.
Thank.
G
You
yeah
you've
done
pretty
well,
given
the
slides
have
been
a
bit.
Often,
we've
just
lost
our
speaker
notes,
but
okay
yep.
So
with
recovery,
it's
kind
of
catastrophic
with
an
AOA
if
your
private
key
is
compromised,
you're,
basically
racing
against
an
attacker
to
secure
your
assets,
but
with
a
smart
contract
wallet,
we've
implemented
a
recover
function
that
requires
basically
setting
a
recovery
hash
from
that
hash.
G
Yeah
we've
got
the
notes
now
behind
the
timer
yeah,
so
with
a
recovery
hash.
It
just
consists
of
the
address
that
you're
going
to
trust,
to
call
the
recovery
function
and
the
the
hash
of
the
wall,
the
wallet's
public,
key
that
you're
addressing
and
some
salt,
so
that
you
so
that
an
attacker
can't
actually
deduce
your
recovery
address
or
the
wallet
that
we'll
call
that.
G
So,
when
you
do
call
recovery,
you're
passing
those
parameters-
and
you
are
the
caller
itself,
then
you
can
immediately
reset
your
BLS
key
and
yes,
basically
stop
the
attacker
who
set,
who
may
have
attempted
to
take
some
of
your
assets
or
set
some
of
the
other
functions.
So
if
an
attacker
steals
your
key
and
tries
to
reset
your
key,
they
can't
do
that
because
there's
a
one-week
delay
in
setting
that
parameter
with
your
recovery.
You
can
do
that
straight
away.
G
So
as
soon
as
you
see
a
problem
in
that
someone's
trying
to
set
something
that
you
didn't,
you
can
intercept
it
with
this.
G
We
take
advantage
of
the
fact
that
when
you
first
set
your
recovery
hash,
it
will
set
it
immediately,
but
otherwise
it's
a
secure
function
so
we'll
have
a
delay
and
in
doing
that,
you
can
do
something
quite
fun
with
that
in
that,
if
you
want
to
onboard
your
users,
you
can
put
a
wallet
inside
the
browser
and
have
them
use
that
you
can
send
them
some
assets
like
give
them.
Basically
a
web
2
usability
experience,
but
you
they
actually
have
web
free
assets
in
their
browser
wallet.
G
But
then,
at
some
point
they
may
say
they
may
wish
to
secure
those
assets
further.
So
you
have
the
smart
contract
deployed.
You
have
the
key
inside
the
browser,
but
that's
not
very
secure,
so
you
can
do
something
like
suggest
to
the
user
that
they
set
the
recovery
hash
of
their
browser
wallet,
and
you
can
do
that
via
the
DAP
and
then
from
the
secure
wallet
that
you've
prompted
them
to
install
like
if
it's
our
prototype
extension
quill.
G
We
find
that's
just
a
smooth
way
to
onboard
people
so
where
to
next.
So,
let's
sort
of
start
with
where
we
began.
So
we
were
looking
primarily
at
aggregating
signatures,
obviously
to
reduce
the
call
data
towards
layer,
one
on
Roll-Ups
and
we
wanted
to
I.
Don't
know
the
slides
here
so
yeah
I
wanted
to
leverage
account
abstraction,
which
was
at
the
protocol
layer
first.
So
that
was
the
eip2938
with
that
we
realized
there
could
be
some
delay
for
that,
and
also
that
seems
to
have
paused
since
then.
G
So
we
decided
at
that
time
to
focus
on
a
BLS,
only
signature
scheme,
because
that's
what
we
needed
and
that
would
be
a
contract
wallet.
We
did
some
preliminary
optimizations
like
parameter
deduplication.
So
if
you
have
a
bundle
with
a
lot
of
common
parameters,
you
can
effectively
like
factorization,
you
take
it
once
out
the
front
and
fill
in
the
gaps.
So
something
like
an
airdrop
is
is
really
valuable.
So
if
someone
wants
to
do
an
airdrop,
they
can
send
a
bundle
of
transactions
they
pass
in
one
contract,
they're
interacting
with
it's
one
sender.
G
It's
one
address
it's
calling
it
and
then
yeah.
Some
of
the
parameters
are
the
same
except
for
the
recipient,
and
in
that
case
you
can
effectively
yeah
deduplicate
parameters.
There
you've
got
to
ignore
that
screen.
There
we
go
yeah.
Some
of
the
wallet
features
we
then
focused
on
were
as
Jake
described,
sponsored
transactions,
multi-action,
recoverability
and
upgradability,
and
then
we
heard
about
erp4337
to
start
to
gain
some
interest
in
popularity
and
at
that
time
our
contracts
were
going
for
audits,
so
we're
trying
to
figure
out.
G
Do
we
just
finish
what
we're
doing
or
look
at
that?
So
then
we
decided
to
yeah
look
towards
being
compatible
with
four
through
seven.
So
that's
where
we
are
now
where
to
next.
We
still
focusing
on
aggregating
signatures
for
the
lowest
cost
transactions
on
Layer
Two.
We
will
be
focusing
oh,
my
slides
moving
around.
Thank
you
we'll!
Oh
sorry,
you
got
it.
H
G
That's
good
there
we
go
yeah
so.
G
Thank
you,
the
yep,
so
for
yeah
still
focusing
on
aggregating
signatures,
and
then
we
are
working
on
being
437
compatible.
One
of
our
colleagues
is
almost
there
with
that,
and
I
noticed
is
that
draw
in
the
background,
say:
hi
she's
working
on
4337.
G
What
I
should
explain?
Yeah
4337
is
doing
account
obstruction
on
chain,
so
they've
got
a
basically
a
smart
contract
template
for
that
in
a
structure
for
how
that
will
work
regarding
paying
gas
as
well.
The
way
we
originally
did
it
as
Jake
described,
is
putting
in
a
reward
to
TX
origin
so
that
Mev
Bots
can
process
the
transactions,
but
there's
also
the
way
using
the
Altman
pool
that
4357
proposes.
So
we
can
do
either
of
those
depending
on
what
the
DAP
wants.
Further
optimizations
the
4337
user
operation
contains.
G
You
know
more
gas
parameters
to
take
care
of
the
way
they
do
that,
but
for
when
we
want
to
do
it
the
direct
payment
way,
we
can
again
optimize
those
parameters
out
by
not
passing
them
in
having
a
preceding
function
that
then
populates
them
with
zeros
and
then
from
there.
We
can
do
public
key
mapping,
so
we
have
yes,
smaller
data
sent
in
for
the
larger
addresses,
sorry,
larger
public
keys
and
also
doing
things
like
floating
points.
G
So
if
a
bundle
has
a
lot
of
variables
that
are
actually
within
a
specific
range,
we
don't
need
to
pass
in
a
un256-bit
number
for
each
of
them.
We
can
actually
have
some
smaller
range
for
those,
so
saving
bytes.
Wherever
we
can
there's
a
lot
of
things
we
want
to
do
there,
some
of
the
just
almost
like,
say
a
refactor
phase.
G
G
So
when
we
take
a
step
back,
what
we're
doing
is
lowering
the
transaction
costs
on
Layer
Two
and
when
you
do
that
it
increases
the
number
of
viable
applications
that
can
be
built
or
viable
solutions
that
can
be
put
out
there
to
solve
problems
and
I'd
like
to
sort
of
visualize
it
like
this.
On
the
the
x-axis,
we've
got
transaction
costs
and
we
have
a
lot
of
defy
things
going
on
and
that
works
on
layer
one.
G
Even
if
it's
a
you
know
during
a
busy
time
and
there's
you
know,
high
gas
costs,
a
high
value,
Asset
transfer
is
worth
it.
You
will
pay
a
hundred
dollars
a
transaction
to
move
something
a
significant
value.
Similarly,
if
you're
there's
a
hyped
up,
nft
drop
people
will
spend
the
gas
to
do
it,
but
that's
not
everyone.
That's
a
that's
kind
of
I
would
say
very
small
set
of
population
with
roll
ups.
You
can
get
cheaper
transactions
towards
tens
of
cents
or
less,
and
then
you
can
casual
gaming.
G
It
warrants
that
you
can
spend
tens
of
cents
for
a
certain
type
of
interaction
and
that
works
there.
But
what
we
want
to
do
is
go
towards
this.
We
with
evm
Roll-Ups,
adding
the
BLS
signature
scheme,
gives
you
some
savings
and
obviously
all
the
other
things
that
that
reduce
the
layer
to
transaction
cost
will
open
up
the
applications
towards
a
microfinance
in
developing
economies.
G
So
this
is
where
we
are
now:
we're
live
on
arbitrim
Nitro,
geoli
test
net
and
we're
going
to
be
deploying
to
arbitrum
and
optimism
after
some
autofixes
and
other
layer
twos
that
evm
compatible
or
equivalent
we'll
seek
to
do
what
basically
get
this
into
wallets
currently
and
to
encourage
Dutch
to
use
it
so
we'll
first
Target
applications
where
this
will
have
a
direct
benefit
to
help,
help
sort
of
priced
out
users
and,
of
course,
support
regular
web
free
wallets
with
integration
via
4337,
because
that
seems
to
be
where
the
attention
is
with
wallets
and
further.
G
G
So
this
is
how
it
feels
to
me
that
we've
got
on
the
one
hand,
a
lot
of
real
world
problems,
that
kind
of
a
cut
out
from
the
web,
3
Solutions
due
to
the
cost
per
transaction.
But
we
hope
that
we
sort
of
once
that
joins
in
that
we
will
get
these
real
world
problems
being
solved
by
web3,
Solutions
and
yeah.
G
We
just
sort
of
are
looking
forward
to
that
time,
because
I
think
that's
when
we'll
get
again
a
Resurgence
of
a
lot
of
activity,
we'll
have
a
lot
of
users
will
actually
be
able
to
benefit
from
The
Primitives
that
we're
building
that
everyone's
building
in
the
community
So
This
Is
Us,
where
web
BLS
wallet.
If
you
want
to
learn
more
check
it
out
in
browser
demo,
it's
at
BLS
wallet.org,
maybe
don't
hit
it
all
at
once
in
case
it
crashes,
but
it'll
be
fine
check
it
out.
Github,
there's
a
Discord,
web3well
and
yeah.
G
I
can
repeat
the
question:
just
go
for
it.
Yeah.
I
I
G
I
Question
yeah:
okay,
again,
congratulations
for
the
project,
it's
very!
It's
going
to
be
very
useful
to
the
community.
My
question
is:
when
you
create
the
wallet
and
make
this
these
changes
you're
proposing.
That
is
great.
I
You
need
also
to
update
to
the
clients
because,
for
instance,
to
support
the
multiple
transactions
we
want
to
sign
it.
It's
amazing
idea:
are
you
talking
to
the
I,
don't
know
with
execution
layered
clients
to
help
them
to
adopt
their
clients?
How
are
how
are
being
those
conversations.
G
Absolutely
yeah,
so,
quite
a
while
ago
we
we
started
that
Journey
we
started
contacting
I
think
there
was
even
end
of
last
year.
I
started
contacting
some
wallets
just
to
see,
which
ones
might
be
interested.
How
to
begin
that
conversation,
and
so
it's
a
very
good
question.
We
had
some
interest
from
wallets.
Certain
wallets
are
saying
yes,
we
want
to
do
this,
it's
quite
interesting,
but
with
what
we
had,
it
just
seemed
to
not
get
integrated.
G
So
there
was
a
bit
of
a
delay,
I
think
from
wallets,
but
we
were
also
not
live
yet
so
I
think
once
we're
live.
That
will
be
helpful
when
4357
came
about,
which
is
the
on-chain
account
abstraction.
There
was
a
lot
of
conversation
interest
around
that
standard,
and
so
maybe
the
wallets
will
integrate
that
standard
sooner
and
then
we
can
have
those
conversations
again
and
to
say
look
here
is
an
implementation,
and
these
are
the
features
of
this
one
and
I'm
sure
there'll
be
other
implementations
for
other
signature
schemes.
G
So
there
will
be
a
change
on
the
wallet
side
so
that
they
have
to
sign
with
a
different
signature
scheme
and
then
obviously
in
the
UI,
and
all
that,
apart
from
the
quill
extension,
which
is
the
basically
a
reference
browser
wallet,
we've
also
gone
through
a
large
design.
G
I
guess
yeah
a
large
design,
a
set
of
design
and
to
look
at
what
future
wallets
can
look
like.
So
these
can
form
a
bit
of
a
you
know,
a
bit
of
design
help
for
wallets
as
well.
G
G
That's
okay!
Now
the
diagram
maybe
shows
it
better.
Well,
this
is
a
bit
slow
yeah,
so
the
the
nodes
don't
need
to
change
so
so
the
clients
that
they
say
the
aggregators.
Here
we
go
this
one.
So
at
the
moment
we
have
a
dedicated
server
that
will
do
the
bundling.
We've
already
had
conversations
with
one
particular
Layer
Two
about
this
to
say
that
they
would
want
to
integrate
this.
So
for
us,
that's
been
not
been
the
barrier.
G
We've
heard
great
enthusiasm
from
the
layer,
two
networks
to
say
as
soon
as
wallets
are
doing
this
they're,
going
to
put
it
in,
like
the
nodes,
have
a
vested
interest
to
reduce
their
costs
so
like
for
us,
that's
been
a
like
that
was
I
did
an
early
litmus
test
in
a
sense
to
talk
to
them
and
they're
like
if
this
is
in
the
wallet
we'll
put
it
in
the
next
day,
almost
like
that
was
the
the
signal
I
got
from
them,
but
as
it
stands,
this
is
one
solution.
G
The
4337
solution
is
a
little
different
because
I
think
it's
an
alternative
mempool
but
yeah
maybe
check
out
their
talk
for
more
information
on
that.
We've
got
a
couple
of
questions
over.
Oh
sorry,
over
here,
yep.
H
Hey
Jesse
from
coinbase
two
questions:
one
is:
if
we're
exploring
kind
of
eip3
437,
is
there
anything
specific?
We
should
be
keeping
in
mind
with
BLS
to
make
sure
that
there's
like
compatibility
there
just
on
the
coinbase
side
and
then
the
second
question
is:
how
does
the
atomicity
actually
work
in
the
user
operation
transactions
how's
that
actually
implemented
and
like
executed
on
the
actual
layer,
yeah.
E
Both
the
the
current
I
think
it's
f,
infantilism
is
the
repo,
and
our
wallet
under
the
covers
are
using
the
same
BLS,
verification
and
solidity
and
also
the
same
client
libraries.
So
they
should
be
largely
compatible
for
that
yeah.
G
And
and
yeah
regarding
the
what's
required
on
your
side,
it
will
just
be
the
signing
like
the
client
side
would
just
need
to
sign
the
BLS
signature
for
that
part
and
then,
depending
on
which
way
you
go
directly
or
via
4337.
It
will
just
be
interacting
with
the
contract
wallets
that
it
deploys.
The
second
question:
sorry,
what
was
the
second
one
again,
the
oh
yeah,
sorry,
that's
right!
So
for
the
multi-actions
we
have
a
set
of
it's.
G
Basically,
an
array
of
actions
inside
a
user
operation
and
and
I
think
437's
done
the
same
thing.
It's
it's
the
same
format
that
you
can
specify
a
set
of
actions.
I
use
a
so
yeah,
it's
kind
of
a
cascaded
function,
so
that
I
can
call
a
try
on
one
of
them,
and
so,
if
one
of
the
actions
fails,
then
it
reverts
and
then
so
all
of
them
revert
within
that
try
and
then
I
catch
and
then
I
go
on
to
the
next
user
operation.
G
J
Yep,
who
do
you
anticipate
running
these
aggregated
proxies.
E
Yeah
to
start
out,
we
would
expect,
like
the
app
would
probably
run
its
own
aggregate
proxy
just
to
kind
of
like
bootstrap
the
process.
Eventually,
it
could
potentially
be
like
a
larger
swath
of
say,
like
nodes,
having
compatibility
with
that.
We
also
think
that,
if
we're
able
to
kind
of
move
more
towards
that,
like
contract
funding
for
the
gas
that
will
make
it
so
it
does
not
matter
kind
of
where
you
submit
it
when
it
eventually
is
executed
on
chain.
E
K
For
this
presentation
appreciate
it
does
quilt
have
any
sort
of
priority
on
test
automation
for
end-to-end
testing.
You
know,
usability
testing
seems
like
wallets
right
now.
Don't
pay
very
much
attention
laser.
G
Yeah,
no
definitely
that's
a
very
good
question,
so,
firstly,
the
quill:
isn't
we
don't
want
to
release
quill
as
a
wallet?
It's
meant
to
be
like
a
reference
implementation
to
show
how
other
wallets
can
integrate
the
client.
We
had
considered
spending
more
effort,
making
the
UI
match
the
designs
that
have
come
about
so
the
designs
we
have
over
there.
G
So
we've
done
that
as
more
of
an
exercise
to
say
this
is
what
wallets
can
do,
but
again
we
had
considered
putting
that
into
quill,
but
because
we
don't
want
to
necessarily
launch
it.
We
leave
them
there
as
reference
implementations,
quill
being
the
technical
one
and
the
design
being
for
other
wallets
to
learn
from.
If,
if
that's
a
value,
so
there
was
some
user
research
done
with
that
as
well
and
yeah
I
think
we
still
have
some
time
for
questions.
We've
got
another
yep.
We've
got
a
question
up
the
front.
L
Thank
you
so
much.
This
is
amazing.
I'm
just
learning
about
BLS,
so
don't
mind
if
my
question
is
too
naive,
but
with
developments
like
ZK
evm
on
layer,
2's
for
Signature,
aggregations
and
atomicity,
like
I,
can
basically
do
like,
as
you
should
like,
approve
and
then
transfer
like
bunch
of
things.
What
do
you
think
about
like
recursive
proofs?
So
if
I've
I
have
like
multiple
transactions,
I
have
each
group
and
I
take
them
and
just
submit
recursive
proofs?
So
in
that
case,
how
like?
E
Yeah
I
think,
and
you
might
have
a
classmates
too
James
I
think
we
haven't
really
fully
looked
into
what
it's
going
to
look
like,
but
we
think
this
wallet,
Blitz
wall
ecosystem,
would
work
in
any
evm
compatible
system,
and
so
we
might
be
able
to
even
reduce
some
of
the
data
that
needs
to
be
proved
or
run
over
in
those
ZK
evm
setups.
But
I
we
haven't
done
a
ton
of
experimentation
yet,
but
there
is
the
possibility
that
it
will
help.
M
C
All
right,
thank
you,
so
much
for
that.
Next
up
is
a
talk
by
Patrick,
who
claims
to
be
an
intern
at
infuria
and
in
the
past
has
been
an
assistant
professor
at
many
universities.
Please
welcome
Patrick
for
his
talk
on
validating
Bridges,
Roll-Ups
and
plasmas.
N
O
O
Yeah
or
is
that
it
awesome
on
I've
got
a
timer,
that's
great,
that's
way
longer
than
anticipated,
so
hi
everyone,
my
name
is
Patrick
McCory
and
today,
I'm
going
to
hopefully
come
across
or
give
across
a
better
mental
model
for
Roll-Ups
and
bridges.
So,
just
before
I
begin
Has,
anyone
used
the
rule
up.
Has
anyone
who's
like
are
most
people
here
awesome
and
when
you
used
it
like
did
you
feel
like
it
was
like
more
secure
than
using
coinbase
or
hey
Rachel?
However,
you
think
it's
secure,
maybe
that's
a
good
phrase.
O
Only
one
person-
that's
great
clearly
degen's
here,
okay,
so
hopefully
by
the
end
of
this
you'll,
have
a
good
idea
of
what
it
means
for
these
systems
to
be
secure
and
whether
they're
actually
secure
or
not,
is
a
whole
whole
different
world.
O
So
the
whole
point
of
Roll-Ups
and
everything
we're
trying
to
build
is
really
just
Bridge
engineering.
All
we're
building
are
bridges.
So,
let's
consider
the
coinbius
bridge
your
own
ethereum.
You
lock
your
phones
into
this
bridge
and
then
it
magically
appears
on
coinbase
you're
going
coinbius.
You
transfer
your
assets.
You
buy
some
coins.
You
sell
some
coins,
you
lose
some
money,
you
make
some
money
and
then
eventually
you
want
to
get
your
coins
back
to
ethereum,
and
so
your
ping
coinbase
and
say
coinbase.
O
Let
me
withdraw
my
1000
eighth
because
I'm
a
wheel
and
then
what
you'll
imagine
is
that
coinbase
will
send
a
message
to
the
bridge
they
say:
Bridge.
Let
Alice
withdraw
her
1000.
Eighth.
Now,
from
the
perspective
of
the
bridge,
the
bridge
has
to
be
convinced
that
Alice
is
entitled
to
this
1000
eighth.
So
how
does
the
bridge
check
this?
In
the
Columbia's
example,
the
bridge
will
just
blindly
trust
coinbase.
O
If
coinbase
says
Alice
is
entitled
to
one
thousand
eight,
then
Alice
will
get
her
1000
each
and
then
it
gets
sent
off
and
we're
all
very
happy
now,
generically
speaking
what's
happening
in
this
type
of
interaction,
generically.
There's
this
all
chain
database,
the
OMG
and
database
records
the
account
balances
the
program
State
the
program,
smart
contract
code.
You
know
everything
that
a
database
you
probably
have,
but,
most
importantly,
it's
recording
the
liabilities
of
the
system.
O
If
you
have
10
coins
in
the
database,
then
you're
owed
10
coins
from
the
bridge
and
the
bridge
has
the
assets
and
the
whole
point
of
these
rule
Ops
or
these
layer.
Two
systems
is
to
guarantee
that
the
Assets
in
the
bridge
can
cover
the
liabilities
in
this
off-chean
system,
and
so
we
have
to
consider
everything
from
the
Bridge's
perspective,
because
it's
up
to
the
bridge
to
protect
your
funds,
but
this
trust
assumption
has
evolved
over
the
years.
After
all,
we've
all
used
bridges
for
the
past
10
years.
O
O
Then
we
moved
on
so
well.
Can
we
have
a
multi-authority
bridge?
You
know,
instead
of
just
trusting
coinbius
kubi
trust,
five
out
of
nine
validators
to
protect
the
funds,
and
then
we
went
a
little
further
and
thought
well.
What
about
these
cryptoeconomic
Bridges?
You
know
what,
if
I
could
stick
assets
and
then
become
a
validator
and
appoint
myself
to
protect
the
funds.
O
Now,
in
all
three
cases,
especially
these
crypto
economic
Bridges,
they're,
still
just
multi-authority,
so
in
late,
2021,
around
six
entities
represented
I,
believe
85
percent
of
the
stake
on
polygon
and
as
these
six
entities
that
you're
trusting
to
protect
the
Assets
in
the
polygons
proof
of
stake
Bridge,
if
they
collude,
they
can
steal
your
funds,
but
so
far
they've
actually
done
a
pretty
good
job.
But
in
all
these
cases
it
sucks.
You
know
we're
trusting
less
than
Tam
people,
our
tan
parties,
to
protect
billions
of
dollars.
O
You
know
the
whole
point
of
cryptocurrencies
was
to
remove
the
intermediaries
and
now
we've
just
reintroduced
them.
Now,
there's
ten
of
them
that
will
protect
most
assets,
but
it
doesn't
suck
from
an
ideological
perspective.
It
sucks
practically
because
they
keep
getting
hacked
I
mean
maybe
a
good
reason.
Hansier
who's
ever
lost
money
with
a
third
party
service.
O
Look
at
this
yeah
found
the
D
gens
I
hope
you
didn't
use
a
Luna,
but
anyway,
but
you
know,
but
basically
they
all
keep
getting
hacked.
The
biggest
hack
was
monk
Ox.
You
know
they
lost
nearly
six
percent
of
all
Bitcoin
that
will
ever
exist
around
800,
000
Bitcoin
or
about
6
800,
give
or
take,
and
now
we
sort
of
just
you
know,
put
it
under
the
table
and
we
just
pretend
it
didn't
happen.
But
you
know
it's
it's
very
frustrating,
but
why
did
this
happen?
O
It
helped
like
these
hacks
occur
because
in
reality
we're
taking
a
set
of
human
processes,
we're
implementing
these
human
processes
and
we're
trying
to
protect
billions
of
dollars
and
humans
don't
scale.
So
every
time
we
take
the
human
processes
and
instantiate
it
somewhere
else
to
protect
more
funds.
You
know,
there's
this
increases
the
likelihood
that
it's
going
to
fail
and
then
they
get
hacked
what
about
a
multi-authority
bridge.
You
know
that
should
be
a
they're
a
little
better
in
practice.
You
know,
there's
more
targets
to
hack
but
of
course
the
Ronan
Bridge.
O
You
know
five
out
of
nine
validators
were
compromised
and
they
lost
their
funds,
although
in
reality
it's
not
really
five
validators,
because
four
of
them
belong
to
one
company,
but
you
get
the
idea.
You
know
multi-authority,
Bridges
and
I
feel
like
over
the
past
10
years.
When
we're
designing
these
Bridges
we've
sort
of
forgot
about
our
old
school
motto.
You
know
not
your
keys,
not
your
coins.
You
know
where
blind
leads
has
given
our
coins
away,
I'm,
just
hoping
they
can
protect
the
funds.
O
So
the
question
for
these
Bridges
is,
you
know:
can
we
build
and
transact
on
an
off-chan
system
by
still
allowing
users
to
maintain
custody
of
their
funds
and
not
have
to
trust
the
operator
to
protect
the
funds?
And
this
was
the
original
goal
of
the
sidechain
paper
in
2014..
They
don't
use
the
word
Bridge,
they
use,
they
call
it
a
two-way
Peg,
but
the
ideas
of
our
history
of
forward.
You
take
your
Bitcoin,
you
lock
it
into
a
bridge
and
it
appears
on
an
experimental
blockchain.
O
So
this
is
the
ethereum
example.
You
know
you're
on
ethereum,
you
lock
it
on
an
experimental
blockchain.
You
transact
a
way,
then,
eventually,
you
bring
your
funds
back
to
ethereum
now
in
the
psychium
paper.
The
idea
is
that
there
would
be
a
smart
contract
on
ethereum
in
this
case.
That
would
check
you
know
the
the
consensus
protocol
off
the
other
system.
That
may
be
as
proof
of
work,
maybe
the
validators
of
that
system,
but
there's
a
smart
contract
here
with
the
assets.
Just
checking
of
the
other
blockchain
agrees
that
the
funds
should
be
withdrawn.
O
But
the
issue
is
that
when
you
have
a
consensus
protocol,
you're
still
trusting
the
Judgment
of
a
set
of
parties
and
and
there's
two
that
you
know
ways
this
is
trusted
the
first
kiss.
Is
you
know
what?
If
the
consensus
protocol
agrees
to
an
invalid
block,
you
send
it
to
the
bridge.
The
bridge
gets
the
invalid
block,
but
all
of
the
validators
agreed
again
your
funds
get
stolen.
Now
you
could
use
a
validity
proof
or
zero
knowledge
proofs
to
make
that
a
little
better
and
there's
a
lot
six
years
of
work
to
make
that
better.
O
But
the
real
issue
with
the
side
chains
or
the
side
chain
paper
was
availability.
Now
one
of
the
experimental
blockchain
goes
offline
and
The
Operators
disappear.
If
the
operators
disappear,
the
consensus
protocol
stalls,
it
can't
make
any
more
decisions
and
then
your
funds
get
stuck
on
the
bridge
and
you
can
never
get
your
funds
out.
So
that
was
the
issue
with
the
sidechain
paper.
O
So
again,
I'm
going
to
ask
a
better
question:
you
know:
can
we
build
a
bridge
that
can
protect
us
from
an
all-powerful
adversary?
So
even
if
the
entire
system
goes,
offline,
I
can
still
get
my
funds
out,
and
this
was
the
cooler
plasma
you
know
back
in
2017
the
plasma
paper
came
out.
Has
anyone
tried
to
read
the
paper
by
the
way?
You
know
that?
Okay,
maybe
a
better
question,
did
anyone
read
it
and
understand
it?
O
Noah
look
at
that.
I
met
I
spoke
to
Joseph
recently
and
he
called
it
aspirational
in
terms
of
his
writing,
because
it's
a
very
difficult
paper
to
read.
But
the
idea
in
the
paper
was
amazing:
it
tried
to
solve
that
availability
problem
that
liveness
problem.
So
even
if
the
entire
system
goes
offline,
you
can
still
get
your
funds
out.
You
know
I
tried
to
do
better
than
this
IGN
paper
and
for
about
two
years
as
a
community,
we
had
all
these
different
variants
of
plasma.
O
You
know
plasma
cash,
you
know
plasma
and
partial
spending,
whatever
plasma
MVP,
but
none
of
the
solutions
were
satisfactory.
You
know
they
only
supported
payments.
They
all
have
these
nitty-gritty
details
that
made
it
not
practical
and
in
a
way
we
sort
of
wasted
two
years,
but
we
didn't
really
waste
two
years
then
eventually,
Barry
whiteheart
came
along
and
he
just
released
as
GitHub
and
total
ethereum
style.
That
really
you
know,
helped
simplify
the
design
space.
O
He
separated
out
data
availability
on
making
sure
the
updates
to
the
database
are
valid,
and
you
know
the
way
he
solved.
It
was
the
roll
up
where
you
roll
up
the
transaction
data
and
you
just
post
it
to
ethereum.
Then
all
you've
got
to
solve
is
making
sure
the
data
is
correct
and
valid,
and
this
led
to
the
Roll-Ups
this
wonderful
little
GitHub.
Now,
if
we
want
to
categorize
this
as
a
bridge,
we
would
call
this
the
validating
Bridge,
because
now
the
bridge
will
end
a
bit
independently
protect
the
funds.
O
So,
let's
give
an
example,
we
have
an
Executor
and
they
want
to
update
the
off
chain
database.
So
they
do
this
1990
automation,
the
update
the
database
and
they'll
propose
an
update
to
the
database
to
the
bridge.
Now
the
bridge
will
not
blindly
trust
the
executor,
regardless
of
who's
authorized.
This
update.
It
will
not
trust
the
executor,
it
must
be
independent
or
it
must
independently
be
convinced
that
this
update
is
valid
and
correct,
and
that
updates
frequently
occur
as
well.
O
So
then,
the
executor
has
to
send
convincing
evidence
for
why
this
is
valid,
that
you
know,
and
then
the
bridge
will
check
the
evidence
check
how
frequent
it
is
and
say,
yep
the
off
chain
database
is
correct.
The
liabilities
are
fine,
I
can
let
the
user
withdraw
their
funds,
and
this
is
what
the
rule-ups
are
trying
to
build.
O
You
know
the
loop
brings
optimistic
ethereum
ZK,
seeing
Stark
arbitrim
they're
all
trying
to
build
a
validating
Bridge,
and
if
they
can
build
this,
then
that's
really
exciting,
because
now
we
can
have
a
bridge
that
runs
in
ethereum
and
it's
ethereum.
That's
protecting
your
funds
from
the
adversary.
You
know
they
try
to
steal
your
funds.
Nope
they
try
to
censor
your
transaction
nope.
It
will
always
try
to
defeat
this
all-powerful
adversary.
You
know
it's
a
great
great
punch,
isn't
it,
but
this
sounds
cool.
O
O
We're
going
to
talk
about
here
are
the
agents
you
know
who's
involved
in
the
protocol,
we're
going
to
provide
a
high
level
overview
of
how
it
works,
then
the
threat
model
and,
of
course,
the
security
properties
for
what
it
means
to
be
secure,
so
who's
involved
in
the
protocol.
First,
we
have
the
honest
user
or
an
honest
party.
The
honors
user
really
just
wants
to
you
know
lock
their
Moon
cat
into
the
system,
buy
and
sell
their
Moon
cat
and
then
get
their
Moon
cat
back
out.
Now
they
don't
really
care
about
the
system
itself.
O
O
That's
I
know:
let's
watch
this
in
action,
so
you
have
Alice
and
Alice
will
deposit
one
coin
into
the
bridge.
Then
this
will
magically
appear
in
the
off
chain
database.
Then
Bob
comes
along.
You
know,
hi
Bob
and
I'll
just
go
on
to
send
one
coin.
The
Bob
so
she'll
sign
a
transaction
and
give
it
to
the
sequencer.
O
Now
the
sequencer
can
notify
Bob
and
say
Bob
you're,
going
to
receive
one
coin,
but
what's
important
is
that
that's
only
a
promise
the
transaction
is
in
public,
it's
not
vital.
It's
not
even
pending
it
simply
held
by
the
sequencer.
So
when
you
send
a
transaction,
an
arbitrim,
it's
the
sequencer,
that's
getting
it
and
it's
making
a
promise
to
you
that
it
will
be
executed.
But
it's
just
a
promise.
O
The
sequencer
waits
around
for
a
while
more
transactions
come
in
then
eventually
the
sequencer
will
order
the
transactions
and
pass
it
on.
In
this
example,
the
sequencer
will
give
the
transactions
directly
to
the
bridge.
The
bridge
will
order
the
transactions
but
they're
not
yet
executed.
We
need
someone
to
come
along
to
execute
the
transactions,
so
the
executor
comes.
He
picks
up
the
transactions
again,
the
wonderful
1990
animation.
He
executes
the
transactions
and
he'll
post
a
checkpoint
to
the
bridge
and
he'll,
say
Bridge.
O
Here's
an
update
to
the
database,
and
this
is
why
it
is
valid,
and
this
happens
continuously.
You
know
we
order
transactions,
we
execute
transactions,
and
then
we
convince
the
bridge
that
this
is
correct
and
valid,
and
that
convincing
is
again
the
most
important
part
of
a
bridge
or
a
validating
Bridge,
so
who's
the
adversary.
You
know
who
are
we
trying
to
defend
against
who's,
trying
to
steal
our
funds?
O
So
there's
two
aspects
to
consider.
First,
the
masses
flow
control,
the
adversary,
can
view
reorder
and
drop
all
messages
on
the
layer
2
system.
The
only
guarantee
that
an
honest
party
has
is
that
they
can
send
a
transaction
to
ethereum
and
to
the
bridge.
That's
the
only
guarantee
they
get
from
Massey's
delivery.
O
The
other
one
is
that
the
adversary
can
corrupt
nearly
every
single
party
on
the
off-chean
system.
We
simply
assume
that
the
bridge
cannot
be
corrupted
and
there's
one
honest
party
who
can
assist
the
bridge.
That's
the
only
guarantee
we
get
in
terms
of
honest
parties.
Everything
else
can
be
corrupt
and
evil
and
out
to
steal
our
funds,
and
this
is
the
most
powerful
adversary
that
you
can
or
you
can.
You
have
to
defend
against.
O
You
know:
they'd
literally
control
the
entire
all
chain
system,
and
if
you
look
at
L2
beats,
you
will
notice
that
no
rule
up
today,
the
smart
contract
enabled
can
actually
defend
against
this
Beast,
the
very
very
difficult
adversary
to
beat-
and
it's
probably
going
to
be
another
year
or
two
before
a
rule.
App
can
defeat
this
Beast.
O
So,
what's
the
security
properties,
then
what
does
it
mean
to
be
secure
for
a
roll-up
or
a
validating
Bridge,
the
overall
goal?
The
overarching
goal
is
that
there's
this
off-chain
database.
We
have
to
protect
the
safety,
honest
liveness
and
there's
three
sub
goals
and
again
these
sub-goals
are
from
the
perspective
of
the
bridge,
because
all
that
matters
is
the
bridge
the
bridge
has
to
have
a
guarantee.
You
know,
is
the
data
available,
that's
data
availability?
Can
anyone
get
a
copy
of
the
data?
O
The
second
property
is
State
transition.
Integrity,
is
you
know
from
the
bridges
perspective,
are
all
proposed,
updates
to
the
database
valid
and
correct
and
finally,
censorship
resistance?
If
the
entire
system
goes,
all
flying,
can
the
bridge
independently
forcefully
order
and
eventually
execute
transactions
that
make
sure
you
can
unwind
your
position
and
withdraw
your
funds
from
the
system.
O
So
what
about
data
availability?
You
know
what
is
this
problem
and
there's
three
questions
we're
going
to
answer.
You
know:
why
does
the
data
need
to
be
public?
What
data
needs
to
be
public
and
how
do
we
guarantee
it's?
How
do
we
guarantee
that
it
is
publicly
available?
So
why
do
we
care
about
the
database
being
public?
Remember
we
had
one
assumption,
there's
one
honest
party
out
there
who
can
assist
the
bridge,
so
anyone
here
ideally
could
help
the
bridge
you
know
protect
from
the
all-powerful
adversary.
O
So
the
only
way
the
honest
party
can
help
is
that
they
have
a
copy
of
the
database.
You
know
they
need
a
copy
of
the
most
recent
database,
so
they
can
take
the
transactions,
execute
them
and
actually
propose
an
update
to
the
bridge.
If
the
adversary
can
withhold
One
update
and
prevent
anyone
from
getting
an
up-to-date
copy
of
the
database,
then
they
you
know
they
win
the
game
and
you
can't
propose
an
actual
update.
So
that's
why
it
has
to
be
public
for
one
honors
party.
O
What
theater
needs
to
be
public
and
this
sort
of
varies
between
you
know
the
optimistic,
real
apps
and
the
validity
Roll-Ups,
but,
generally
speaking
enough,
data
has
to
be
public,
so
the
honest
party
can
compute
the
database
so
it
needs.
You
know
all
the
updates
to
the
database
and
there's
two
types
of
data.
One
is
transaction
history,
you
know
get
out,
get
the
entire
list
of
order
transactions
sort
of
like
a
blockchain,
execute
the
transactions
and
then
you'll
create
a
copy
of
the
database.
O
Or
you
know
you
have
database
database
B,
you
get
the
state
diff,
you
know
the
difference
in
the
storage
values
and
you
can
post
the
state
diff,
and
so,
as
a
you
know,
as
a
user,
you
get
the
state
diff
applied
to
your
database
and
then
you
compute
the
new
database.
So
there
you
hide
the
transactions,
you
only
see
the
result
of
the
transactions,
but
in
both
cases
that
has
to
be
valid.
O
And,
finally,
how
do
we
guarantee
the
data
is
publicly
available
so
in
plasma?
The
focus
was
this
challenge
process
you
know,
could
I
challenge
the
operator
that
make
the
data
available,
but
for
many
years
it
was
considered
too
complicated
too
complex.
Today,
I
think
you
could
solve
that
problem
in
a
reasonable
manner,
but
most
of
the
communities
just
ignore
it.
The
other
problem,
the
other
way
to
solve
it
is
a
committee
is
take
this
starknet
committee
or
the
any
trust
committee
I
think
is
arbitrum
Nova.
O
O
So
what
about
the
state
transition?
Integrity
problem?
Well,
this
is
very
straightforward.
If
one
object
to
the
database
can
include
a
can
include
an
invalid
transaction,
then
the
adversary
can
steal
all
the
funds
in
the
system.
You
know
we've
seen
this
time
and
time
again
with
all
of
the
bridges,
the
most
recent
one
being
binance.
You
know
it's.
This
is
how
they
keep
stealing
the
funds.
Now,
there's
two
different
ways
to
solve
this
problem:
there's
optimistic
or
ZK,
fraud,
proofs
or
validity
proofs.
O
You
know
you're
going
to
hear
about
this
topic
over
and
over
and
over
again,
because
this
is
the
one
thing
they
all
talk
about.
You
know
this
is
the
most
important
problem
in
their
mind.
So
I'll
skip
it
for
now,
but
to
me
the
most
important
problem
that
no
one
talks
about-
and
this
is
really
the
difference
between
the
sidechain
paper-
you
know
what
is
a
side
chain
and
what
will
be
a
rule
up
or
a
layer.
Two
protocol
is
censorship.
Resistance.
O
O
He
gives
the
transaction
to
the
sequencer
and
the
sequences
like
no,
no
I'm
not
going
to
let
you
sell
your
mooncat,
you
know
how
dare
they?
The
user
should
be
able
to
forcefully
order
this
transaction,
so
the
user
will
simply
tick
their
transaction
and
send
it
directly
to
the
bridge.
This
is
what
we
call
forced
inclusion.
They
send
it
to
the
bridge
and
the
bridge
will
force
its
ordering
and
now
is
ordered
for
execution,
and
this
is
really
cool
because
then,
if
we
consider
liveness,
you
know
how
do
we
guarantee
this
eventually
gets
executed?
O
We
can
assume
that
the
sequencer
has
absolutely
nothing
to
do
with
censorship,
resistance
whatsoever.
You
can
have
a
centralized
front
end
a
centralized
sequencer,
but
the
back
end
is
decentralized
and
that's
cool.
That
provides
an
amazing
user
experience
because
you
know
exactly
what
sequencer
they
interact
with,
but
they
are
not
responsible
for
protecting
the
system.
We
really
assume,
there's
one
honest
executor:
you
can
join
the
system,
take
the
transactions,
execute
them,
and
then
you
know
post
the
update
to
the
bridge.
We
just
need
one
honest
party
to
protect
the
system.
O
So,
to
summarize,
if
you
can
solve
all
three
problems,
then
maybe
we
can
slay
the
Beast
and
just
you
know,
deploy
a
secure
layer
to
your
system
and
for
the
ogs
out
there.
This
is
the
bare
wheel
from
2014.
You
know
the
I
think
the
you
know
three
bear
markets
before
and
I
replaced
the
Bitcoin
shield
with
an
ethereum
Shield,
because
Heath
is
money
now,
but
anyway,
what
I
want
to
finish
off
with
is
there's
these
three
core
problems.
O
Are
they
not
the
only
problems,
there's
a
whole
host
of
other
problems
that
you
can
get
your
you
know
teeth
into
if
you're
interested
in
solving
cool
problems
about
real
Labs
as
I
mentioned
censorship,
resistance
is
non-trivial,
there's
a
lot
of
nitty-gritty
details
that
makes
it
difficult
what
I
am
excited
for
are
those
experimental
virtual
machines.
This
was
this
was
the
original
goal
of
the
sidechain
paper.
You
know
we
lock
our
coins
in
Bitcoin
and
we
unlock
it
on
this
experimental
blockchain,
and
now
we
have
this.
You
know
we
have
Cairo
for
starknet.
O
We
had
the
arbitrine
virtual
machine.
We
have
the
optimism
Bedrock,
we
have
fuel
in
their
sway
language.
All
these
really
cool
virtual
machines
and
custom,
you
know
languages
and
software,
but
we're
still
retaining
the
security
of
ethereum
and
that's
probably
the
most
exciting
part
of
these
rule
Ops
as
well
and
finally,
I
guess.
The
last
point
I'll
highlight
is
fragmentation
of
assets.
A
lot
of
people
are
worried
that,
if
you
have,
you
know
10
different
roll
ups,
the
assets
get
fragmented
across
the
Roll-Ups.
Is
that
not
a
problem
for
liquidity?
O
Well,
we've
always
had
this
problem
with
crypto
exchanges.
You
know
you
have
coinbase
crack
and
binance,
so
it's
not
a
new
problem,
but
now
anyone
in
this
room
can
deploy
a
solution
on
something
like
arbitrim.
We
could
quickly
move
your
phone
to
the
optimism
this
you
know
cross
chain
transfers
interruptability.
This
is
now
a
venture
that
anyone
can
build,
or
if
you
tried
to
do
that
in
coinbase,
you
know
coinbase
is
going
to
probably
tell
you
to
go
away.
So
that's
also
really
exciting.
O
O
Now
web
3
is
a
bit
of
a
buzzword,
you
know
I'm,
oh,
if
you're
all
developers
and
we're
all
sort
of
like
oh
well
web3.
Is
this
a
real
thing?
But
to
me
my
vision
of
web3
is
that
if
you
consider
the
web
2
world
web
2,
we've
always
had
to
trust
the
off-chan
system.
I
take
my
coins,
I
lock
it
in
the
coinbase
and
I
really
have
to
trust
coinbase.
To
protect
my
funds
in
the
web.
3
world
I
would
hope
we
can
have
a
user
experience.
O
That's
similar
to
the
coinbius
I
lock,
my
phones
in
a
nice
UI.
You
know
I
get
instant
confirmations,
but
the
difference
is
that
I
don't
have
to
trust
coinbase
for
my
funds,
so
the
actual
service
is
exactly
the
same,
but
the
difference
is
whether
I
trust,
the
operator
or
not,
or
what
I
trust
the
operator
to
do,
and
that's
really
web
three.
So
we
use
these
rule
UPS.
Eventually
it
will
feel
like
using
a
web
2
service,
but
much
better.
You
know
security
and
Trust
guarantees
and
I
hope,
and
this
is
a
coupe
by
vitalik.
O
So,
if
you
consider,
if
you
were
to
do
a
startup,
maybe
five
years
ago,
you
know
you
could
be
the
Newman
gox
or
the
new
bit
Stamper
binance,
you
know
you
run
your
service,
you
get
these
human
processes
and
you
have
to
secure
billions
of
dollars.
That
obviously
doesn't
skill.
It's
very
scary,
you
know
who
wants
to
be
liable
for
protecting
billions
of
dollars?
I
mean
that's
where
his
hands
does.
Anyone
here
want
to
be
responsible
for
protecting
billions
of
dollars?
O
No
one
look
at
that
exactly.
You
know
screw
that
that's
weight,
that's
way,
scary.
So
what
I'm
excited
for
is
the
rule
lumps
if
there's
one
rule
up
that
can
get
a
good.
You
know
a
good
implementation,
that's
easy
to
deploy
and
reinstantiate.
There's
a
good
developer
experience
so
that
anyone
here
can
build
on
it.
Then
we've
solved
the
problem.
You
know,
we've
replaced
those
human
processes
of
software,
but
we
all
move
software
skills.
So
you
deploy
your
rule
up.
You
offer
a
really
cute.
O
Ui
I
can
go
on
there
and
buy
and
sell
my
mooncat,
but
I.
Don't
trust
you
with
it
so
I
believe
it's
worth
it
because
I
don't
think
users
care
about
custody.
You
know
we
all
still
use
custodial
services,
but
it's
the
operators
who
care
no
one
here,
raise
their
hand
when
you
want
to
protect
billions
of
dollars.
O
So
if
you're
all
going
to
do
a
new
startup,
you're,
probably
going
to
look
into
the
rule
out
to
say
you
know,
could
I
reinstantiate
this
and
reuse
the
software,
that's
the
layer,
three
goal,
and
so
that's
why
I
think
it's
worth
it!
You
know.
Custody
is
an
unnecessary
liability
and
that's
the
end
of
my
talk.
I
have
three
minutes
left
I
believe
so.
Thank
you
guys
for
listening
and
have
a
great
time.
C
F
T
Back
got
it:
okay,
I
think
we're
all
set
hello.
Everyone
thank
you
for
coming
or
for
staying.
Those
of
you
who
stay
at
fast,
Patrick's,
talk,
I,
understand,
I,
don't
have
his
Celebrity
Status,
but
yeah
I
will
be
talking
about
sequencers,
Layer,
Two
sequencers
and,
more
generally,
the
principles
of
ordering
and
execution
it'll
be
sort
of
survey
of
the
design
space.
T
There
we
go
cool,
so
the
stuff
that
we'll
be
covering
definitely
covering
I'll
start
with
sort
of
an
introduction
into
sort
of
the
motivation
and
design
rationale
of
kind
of
what
sequencers
are
and
why
we
even
have
them
to
begin
with.
On
Layer
Two,
we'll
talk
about
the
current
state
of
sequencers
in
the
Layer
Two
World.
T
Basically,
that
they're
centralized
but
there'll
be
a
little
more
to
say
than
just
that
and
then
focus
on
ways.
We
can
sort
of
improve
this
state
of
affairs,
trust
minimizing
them,
decentralizing
them
sort
of
limiting
sequencers
power
in
various
other
ways,
and
then,
if
there's
time,
we'll
sort
of
wax
theoretical
about
how
these
Concepts
could
apply
to
layer,
one
to
what
extent
they
do
to
what
extent
they
don't
but
we'll
see
how
things
go.
T
So,
oh
yeah
hi!
That's
me!
My
name
is
Daniel
I'm,
I'm
and
I.
Do
engineering
and
Tech
research
at
off-chain
Labs
we're
the
team
behind
arbitrum
the
layer
two
that
hopefully
you.
F
T
And
yeah
I
won't
be
focusing
on
arbitrum,
but
there'll
be
a
bit
of
like
you
know,
arbitrary
perspective,
arbitrum
bias,
so,
okay
to
get
into
the
subject
of
sequencers,
I,
think
sort
of
the
fastest
way
to
understand
why
we
have
them
is
to
think
about
why
we
even
have
layer
twos
to
begin
with
sort
of
what
we
want
from
layer
twos
right.
So
the
Baseline
starting
point
for
what
a
layer
two
is
is
we're
trying
to
scale
ethereum
while
not
introducing
new
trustism.
T
So,
inheriting
security
from
ethereum,
that's
our
starting
point.
The
scaling
part
is:
we
want
to
improve
the
status
quo
of
what
ethereum
is
like
to
use
in
in
some
other
ways,
there's
all
sorts
of
ways.
It
could
potentially
be
improved
at
Layer
Two,
but
notably
we
want
it
to
be
cheaper,
because
when
layer
one
gets
congested,
it
gets
expensive
and
we
would
also
like
it
to
be
faster,
because
when
layer
one
gets
congested,
it
becomes
slow.
T
T
Forgive
me
what
we've
seen
in
the
layer
two
space
is
that,
basically,
when
we're
talking
about
Layer
Two
in
the
context
of
ethereum,
we're
talking
about
Roll-Ups,
that's
the
design,
that's
dominated
and,
and
that's
in
large
part
I-
think
because
of
the
ux,
the
sort
of
transition
in
ux,
If,
you're
sort
of
used
to
using
ethereum
used
to
layer
one,
it's
actually
just
very
similar.
T
You
can
use
a
lot
of
the
same
tools
it
feels
very
similar,
but
the
key
the
kind
of
key
trick
that
Roll-Ups
use
as
layer
twos
is
they
require
that
you
publish
transaction
data
on
layer,
one
itself
and
by
doing
so
in
a
roundabout
way
that
I
won't
get
into
that
is
sort
of
how
we're
doing
that's.
How
we're
able
to
claim
that
these
things
are
trustlers
that
they
inherit
L1
security,
so
via
layer
2
magic.
T
We
can
sort
of
enforce
the
safety
of
the
layer.
2
Tran
of
the
layer,
2
Chain
after
data
is
published,
but
essentially
all
we're
doing
is
publishing
data
as
far
as
layer,
one
is
concerned,
so
all
of
the
other
work
that
goes
into
processing
a
transaction
validating
it.
Updating
the
state
that
happens
in
a
separate
environment,
we're
not
using
layer,
1
resources,
so
we
can
make
things
cheaper,
so
long
story
short
by
publishing
data
on
layer,
one
we
get
trustlessness.
We
need
that
yeah
we
get
cheaper
transactions.
We
needed
that.
T
The
other
thing
we
said
we
wanted
or
top
of
the
list
of
things
we
wanted
was
fast
transactions
right,
so
do
rollups.
Give
you
fast
transactions,
it
turns
out,
is,
is
kind
of
a
loaded
question
right.
So
if
you,
if
you've
used
any
Roll-Ups,
you've,
probably
noticed
it's
faster
than
using
layer
one,
but
it
sort
of
depends
what
we
mean
by
fast
transactions
and
even
right
here
with.
What's
on
this
slide,
we
can
see
we're
in.
We
have
a
bit
of
a
contradiction
here
right
by
fast.
T
We
mean
faster
than
layer
one,
but
what
I
said
is
that
the
requirement
of
rollups
is
that
we
post
data
on
layer.
One
you
can't
go
faster
than
layer,
one
by
posting
data
on
layer,
one
because
that's
a
circular
problem
or
perhaps
a
triangular
problem,
I'll
I'll,
be
honest.
The
slide
probably
isn't
necessary,
but
I
really
want
to
include
a
trilemma
somehow.
So
this
is
the
new
trilemma
I.
Don't
expect
it
to
catch
on,
but
this
is
another
way
of
thinking
about
the
sort
of
situation
we're
in
with
Roll-Ups
right.
T
We
have
this
nice
feature
of
open
participation,
that's
kind
of
directly
Downstream
from
the
fact
that
we
publish
data
on
layer
one
so
we
can
have
trustlessness,
but
that
means
we
can't
quite
have
fast
finality.
We
can
only
have
two
of
these
things.
There's
other
L2
designs
called
channels
which
give
us
fast
finality
and
trustlessness,
but
those
the
ux
is
very
different.
They
don't
have
the
flexibility
of
Roll-Ups
and
so
on.
T
So
we
kind
of
have
to
decide
where,
in
the
design,
space
we're
going
to
live
and
in
fact,
by
the
way,
if
you,
those
of
us,
the
arbitrary
emojis
in
the
crowd,
who've
followed
our
first
test
net
release.
It
was
actually
you
know
it
had
no
notion
of
fast
transactions.
T
It
was
entirely
like
that
diagonal
line,
the
one
that
says
roll
ups
right
and
as
we
put
that
out,
one
of
the
questions
we
kept
getting
was:
okay,
it's
Layer
Two
are
we
gonna
get
fast
transactions
and
we
kind
of
just
said:
no,
that's
not
really
possible,
but
there
was
clearly
demand
for
it
right.
So
we
kind
of
reached
this.
This
point,
this
kind
of
Middle
Ground
settlement
where
we
said
okay,
what
if
we
can
provide
a
fast
path?
T
That's
trusted,
but
it's
optional,
and
we
were
not
the
first
layer,
two
team
to
come
up
with
this,
or
do
this
by
any
means
pretty
much
all
I'll
do
is
do
this.
We,
in
fact
we
were
actually
came
around
to
this
idea
later
and
the
idea
here
is
you
you
can
imagine,
so
you
have
a
situation
where
there's
some
party,
a
user,
can
trust
them.
The
Trusted
party
says
I
promise
to
include
your
transaction
later
and
then,
hopefully
later
it
does.
T
That's
basically
what
it
comes
down
to
the
sort
of
version
of
this
that
doesn't
work.
The
naive
solution.
Is
you
let
a
user
trust,
whoever
they
want
whomever
they
want.
So
if
a
user
just
decides
I
trust
this
random
party,
that
party
promises
to
include
their
transaction.
T
Even
if
the
party
is
trustworthy,
this
doesn't
quite
work
because
that
party
can't
really
predict
the
future
and
even
if
it
thinks
it
will
include
your
transaction
in
a
given
order,
someone
else
kind
of
might
get
there
first,
so
an
even
to
have
a
trusted
solution
like
this.
You
need
to
sort
of
enshrine
you
have
to
enshrine
a
party
within
the
protocol,
give
it
the
special
permissioned
privilege
and
that's
kind
of
what
the
sequencer
is.
T
So
the
sequencer,
in
other
words,
is,
is
literally
this
party
that
we
give
the
ability
to
directly
post
transactions
into
L2.
Everyone
else
kind
of
has
to
wait.
So
the
sequencer
has
this
narrow,
short-term
view
of
what
will
happen
on
L2.
Therefore,
it
can
give
trusted
trusted
kind
of
soft
confirmation
transactions.
T
We
call
them
so
to
sort
of
recap
that
for
those
who
just
saw
Patrick's
talk,
this
is
a
bit
redundant,
so
I'll
go
quickly,
but
when
we
introduce
a
sequencer,
the
sort
of
life
cycle
of
a
transaction
looks
something
like
this:
the
normal
in
the
sort
of
normal
State
of
Affairs,
the
user
kind
of
gives
their
transaction
off
to
the
sequencer.
The
sequencer
immediately
gives
This
Promise
totally
trusted
that
says.
T
I
will
infield
your
transaction
later
at
some
point
later
in
the
case
of
arbitrum,
usually
every
few
minutes,
It'll
post
a
batch
of
transactions
on
chain,
and
at
that
point
the
sequencer
is
kind
of
out
of
the
picture.
Once
it's
on
chain
we're
in
full
roll-up
mode,
full
trusted
mode.
It's
committed
to
this
particular
ordering
and
as
far
as
a
user
is
concerned,
your
transaction
is
as
finalized
as
a
layer,
one
transaction
right,
because
all
of
the
data
is
available
there.
Anybody
can
execute
it.
T
Anybody
can
see
what
the
final
state
will
be,
the
actual
explicit,
explicit
claim
or
commitment
to
what
that
final
State
actually
is
happens
later
and
the
sequencer
is
not
involved,
and
that's
that
third
step
there.
The
validator
asserts
this
date,
but
there's
no
rush
to
do
that.
That's
really
just
so
that
we
can
communicate
back
to
layer
one
and
process
withdrawals,
but
from
the
layer
if
you're,
just
interacting
on
Layer
Two,
once
your
data
is
on
chain
you're
done.
T
So
that
gives
us
this
way
that
we
can
get
this
nice
fast,
low,
latency,
fast
transaction
path,
rusted,
if
you
want
to,
but
it's
optional,
and
that's
very
important,
so
just
to
drill
that
point
home,
because
you
should
be
suspicious
when
I
start
saying
it's
optional.
What
does
it
mean
that
using
the
sequencer
is
optional?
Well,
if
in
the
sort
of
normal
case
the
system's
working?
T
Well,
if
the
sequencer
gives
you
this
fast
promise,
you
can
just
ignore
it
and
say
screw
you
I,
don't
care
what
you
say:
I'm
going
to
wait
for
you
to
post
on
chain.
So
it
takes
another
few
minutes
and
then
you
get
the
full
sort
of
trustless
modality
in
the
unhappy
case
where
the
sequencer
just
goes
Rogue
and
isn't
even
answering
anything.
There
is
still
a
way
that
you
can
do
anything.
You
want
on
arbitrum
there's
this
sort
of
alternative
path.
T
Basically
long
story
short,
it's
a
lot
slower,
I
think
Patrick
talked
about
this
well
I'm
gonna!
Stop
talking
about
him,
but
it's
on
my
mind
but
yeah.
The
point
is
the
system
can
work
in
a
sort
of
slower
way
in
a
slightly
more
inconvenient
way.
It
can
work
without
the
sequencer
entirely.
So
it's
entirely
optional
and
that's
why
we
can
still
call
this
thing:
a
layer,
two
and
and
and
sleep
at
night.
T
So
I've
just
been
talking
about
the
sequencer
like
it's
my
friend
or
something,
but
you
know
what
actually
is
it
and
basically
you
know
it.
We
just
Define
the
sequencer
as
what
as
this
entity
that
can
give
these
fast
promises.
That
has
all
the
properties
that
I
had.
But
you
might
ask
you
know:
how
does
it
decide
which
transactions
to
include
who
controls
it
and
what
order
of
these
transactions
go
and
so
on?
T
And
you
know
basically
the
design
space
for
what
the
sequencer
is
is
is
pretty
open
it
could
it
could
be
anything
right.
It's
going
to
be
controlled
by
some
smart
contract
you
could
swap
in
whatever
sort
of
mechanism
you
can
think
of,
with
the
one
caveat
that,
because
the
whole
point
is
to
get
fast
transactions,
whatever
mechanism
we
use,
can't
involve
interacting
with
layer
one
because
that
just
defeats
the
whole
purpose
at
least
the
way
I
see
it.
The
way
we
see
it,
other
people
would
describe
it
differently,
but
yeah.
T
It
could
be
all
sorts
of
things.
So
the
current
state
of
affairs
of
what
sequencers
actually
are
in
Layer
Two
as
far
as
I,
can
tell
I
think
at
least
predominantly
most
of
the
layer
two
is
most
of
most
of
the
major
ones.
T
Is
that
they're
centralized
somebody
did
something
Fancy
on
a
layer,
two
that
I
don't
know
about.
You
can
yell
at
me
afterwards,
I
apologize,
but
generally
speaking,
sequencers
are
centralized.
That's
the
status
quo
and
you
know
we
get
asked
about
this
a
lot.
It's
probably
the
most
frequent
question
that
has
to
do
with.
Like
you
know,
Progressive
decentralization
and
decentralization
roadmap
is
like.
When
are
you
decentralizing
to
see?
And
it's
it's
not
a
bad
question.
It's
a
good
question.
T
It's
a
good
thing
to
ask
about,
but
I
think
often
it
comes
from
a
bit
of
a
misunderstanding.
So
there's
kind
of
there's
kind
of
two
things
to
say
to
this.
This
issue
of
centralized
sequences
and
the
first
thing
is
it
might
not
be
as
bad
as
it
initially
appears,
specifically
centralized
sequences
I'm,
suddenly
nervous
someone's
gonna
like
screenshot
this
slide.
If
you're
going
to
screenshot
this
slide
screenshot
the
next
one
too.
That's
all
I
ask
okay,
because
the
next
one
is
very
important.
T
I'm
not
claiming
centralizations
are
fine,
but
the
first
half
of
the
answer
is
the
power
that
a
sequencer
had
is
very
limited
and
circumscribed
right.
It
can't,
for
example,
simply
steal
money
from
the
system
and
it
can't
lock
up
users
funds
forever.
T
So
so
other
parts
of
the
system
are
sort
of
more
important,
even
a
centralized.
Sequencer,
arguably,
could
you
know
you
could
you
could
argue
that
an
L2
could
just
have
a
centralized
sequencer
for
good
that
wouldn't
be
the
end
of
the
world,
and
the
other
thing
that's
worth
saying
here
is
that
you
know
again
on
just
about
every
L2,
certainly
arbitrum
included
in
the
current
state
of
affairs.
They
all
sort
of
have
more
fundamentally
centralized
Parts.
Even
if
we
said
hey,
we
decentralized
the
sequencer.
T
If
we
didn't
take
care
of
those
other
things,
it
sort
of
doesn't
really
give
you
anything.
You
can
read
more
about
that
on
our
docs
or
l2b,
but
you
know
we
don't
want
to.
We
don't
want
to
mislead
by
emphasizing
one
thing
and
not
another,
so
those
other
things
contract,
upgradability
the
power
validators
have
those
are
the
things
that
you
you
know.
If
you
want
to
spam,
our
Discord
about
something
those
are
the
more
important
things,
don't
spend
more
Discord.
T
You
know
what
I
mean:
okay,
important
follow-up,
obviously
having
a
centralized
sequencer
is
not
ideal.
Looking
at
the
time
I'm
going
to
try
to
speed
up
a
little.
So
what
can
a?
What
can
a
decent?
What
can
a
centralized
sequencer?
Do
that's
bad!
Well,
even
if
it's
honest,
honest
mistakes
happen
right,
so
even
an
honest
sequencer
could
have
downtime
because
of
infrastructure
failures
and
server
issues,
and
that's
bad
because
it
sort
of
slows
the
whole
system
down.
It's
very
inconvenient,
I'm
gonna
skip
over
one
thing
in
there.
T
The
juicier
stuff
is
what
if
the
sequencer
is
actually
malicious,
it
just
turns
evil.
What
can
it
do?
Well,
it
can
equivocate.
In
other
words,
it
can
make
one
of
these
promises
and
then
not
make
good
on
it
later.
It
can
make
inconsistent
promises
to
different
users
right
these
fast
transactions
are
trusted.
It
can
violate
that
trust.
It
can't
censor
you
technically,
but
it
can
temporarily
censor
you
right.
T
So
if
it
stops
processing
your
transaction
you'll
be
able
to
get
it
through
eventually-
and
we
like
emphasizing
that
fact,
but
the
also
important
fact
is,
there
is
a
short
window
of
time
that
you'll
have
to
just
wait
and
that
also
could
suck
right
being
unable
to
transact
for
some
number
of
hours
might
be
a
real
problem.
T
The
sequencer
can
can
do
that
to
you
and
then
finally,
the
kind
of
elephant
in
the
room
here
is
okay,
so
all
I
want
to
say
here
there's
plenty
of
other
talks
about
mov
people
who
you
know
have
more
and
more
interesting
things
to
say
about
it,
maybe
than
I
do
I'm,
not
an
expert
I,
don't
even
know
what
the
m
stands
for
it's
unclear
at
this
point
it
was
minor.
Now
it's
maximum
I
learned
when
I
was
procrastinating.
T
T
Has
this
side
effect
that
the
sequencer
has
control
over
transaction
ordering,
which
means,
if
it's
economically
interested
it
might
use
this
to
extract
value.
Whether
this
is
a
you
know,
a
bad
thing.
We
need
to
fix
or
an
opportunity
to
take
advantage
of,
is
sort
of
a
philosophical
debate,
but
we
can
say
this
is
the
case
with
sequencers
right.
We
have
this
power,
we
need
to
at
least
think
about
it
and
yeah.
T
The
way
we
think
about
it
is
is
in
terms
of
sort
of
minimizing
it,
so
I'm
going
to
sort
of
run
through
some
of
the
some
of
the
strategies
that
can
be
used
to
sort
of
improve
this
bad
situation
of
centralized,
sequencers
and
they'll
all
involve
improving
kind
of
one
of
these
one
of
these
four
things
that
made
the
equivocation
blah
blah
blah
Okay.
So
the
simplest
thing
that
we
can
add
to
sequencers
to
make
them
better
a
little
bit
is
the
sort
of
crypto
economic
penalties.
T
We
can
require
sequencers
to
be
staked,
and
we
can
say
now
if
they
particularly
equivocate,
basically
when
they
give
these
off-chain
promises,
they'll
be
signed,
so
think
of
a
signed
promise,
and
then
users
can
use
that
to
prove
that
they
equivocated
and
if
they
equivocate,
we
can
just
slash
the
sequencer.
So
that's
cool.
This
helps
with
the
equivocation
problem,
not
the
other
problems,
and
in
fact
this
could
be
applied
even
to
centralized
sequencers
just
as
easily
really
any
sequencer
mechanism
just
could
and
probably
should
be
applied.
T
A
thing
to
note
here
is
all
we
can
really
do
in
this
case
is
punish
the
sequencer.
We
can't
sort
of
rectify
the
situation
for
users
and
that's
because
if
the
sequencer
is
equivocating,
you
know
each
of
these
claims
are
sort
of
internally
consistent,
they're,
just
inconsistent
with
each
other.
So
it's
not
really
clear,
which
one
is
the
more
valid
one
to
take.
T
You
know
either
way
if
we
simply
took
one
we'd
be
screwing
over
the
other
user
unfairly,
but
all
we
really
can
prove
is
that
the
sequencer
did
something
wrong.
So,
okay,
we
have
this
like
provable
cost
to
equivocation
for
the
sequence,
something
in
terms
of
particularly
the
media
problem
shout
out
to
shutter
here
who's
working
on
this.
T
This
strategy,
I,
probably,
should
have
put
their
logo
bigger
or
something,
but
there's
this
idea
of
threshold
encryption
so
and
sort
of
using
threshold
encryption
to
to
minimize
the
Mev
that
a
sequencer
can
abstract
can
extract,
and
the
idea
here
is
when
a
user
instead
of
Simply
passing
their
transactions
onto
the
sequencer
directly
there'll
be
the
step.
Will
they
pass
it
in
this
encrypted
form
and
they
encrypt
it?
There's
sort
of
this
network,
they
call
them
Keepers,
which
is
kind
of
cute.
T
They
do
this
distributed
key
Generation,
so
you
encrypt
your
transactions,
give
it
to
the
sequencer
the
sequencer
commits
to
an
ordering
blindly,
it
doesn't
know
the
content
of
the
transactions
commits
to
it
off,
Chan
right
and
then
only
after
it
commits
to
them.
Do
we
sort
of
reveal
the
contents
of
it?
So
now
the
sequencer
can't
easily
extract
value
because
it
doesn't
know
what
it's
looking
at.
So
this
is
cool
and
there's
you
know
some
added
levels,
I
mean
so
like
some
potential
concerns.
T
Let's
say
the
the
parties
that
are
in
charge
of
this
distributed
key
generation.
The
idea
is,
you
distribute
it
so
that
they
can't
easily
collude,
but
if
they
do
collude
they
could,
for
example,
reveal
the
contents
of
the
transactions
to
the
sequencer
before
you
want
to
also
if
they
sort
of
don't
reveal
keys
in
time.
Things
like
that,
there's
certain
ways
that
they
can
delay
delay
things
further
and
remember.
T
This
was
kind
of
all
about
improving
latency,
so
we
do
want
to
take
latency
concerns
seriously,
even
in
the
sort
of
normal
case
when
you're
doing
the
threshold
encryption
stuff,
there's
rounds
of
communication
that
are
required.
So
it's
inevitably
going
to
add
some
latency.
So
that's
that's
one
concern
in
our
eyes,
but
yeah
cool
stuff,
so
I
mean
these
two
techniques.
So
far
again,
you
could
apply
these
to
a
centralized
sequencer.
We
haven't
really
talked
about
decentralizing
it
just
limiting
its
power.
T
Now,
let's
get
to
some
ideas
for
more
properly
decentralizing
it.
T
So
one
design
space,
let's
say,
is
that
of
Mev
auctions,
as
it's
known
proposed
by
some
of
the
folks
at
optimism,
along
with
a
few
other
some
years
ago,
I'm
not
claiming
but
I'm
gonna
describe
it
sort
of
in
the
abstract.
I'm
not
claiming
this
is
their
plan
or
anything
like
that.
Just
sort
of
talking
about
the
design
space.
So
the
idea
here
is,
you
can
imagine
at
any
given
time
we
can
point
to
who
the
sequencer
is.
T
It's
still
one
specific
party,
even
a
centralized
party,
but
every
so
often
over
time
we
hold
an
auction
and
you
can
buy
the
right
to
become
the
team.
Okay
and,
and
so
in
that
sense
it
becomes.
You
know
in
the
big
picture
permissionless
now.
Why
would
you
want
to
be
a
sequencer
seems
like
a
thankless
job?
The
answer
is
by
being
a
sequencer,
you
have
the
you,
have
the
power
and
the
ability
to
profit
by
extracting
it
by
extracting
Mev.
T
So
this
this
design
kind
of
leans
into
the
media,
thing
and
kind
of
says
yeah.
Let's
take,
let's
take
advantage
of
this
and
use
Med
as
a
revenue
Source
again
that's
sort
of
a
philosophical
distinction
or
an
ideological
one,
even
in
terms
of
how
we
want
to
handle
it.
T
I
think
important
in
the
mental
model,
for
these
is
that
these
auctions
kind
of
have
to
be
infrequent.
It's
not
as
though
you
know
it's
not
as
though
these
potential
sequencers
are
sitting
looking
at
transactions,
seeing
ways
to
extract
value
from
particular
transactions
and
then
bidding
on
the
rights
to
order
them
it's
more
like
they're
bidding
on
their
future
potential
for
ordering
they're
taking
a
bet
on
their
own
Mev
powers
in
the
future.
T
They
can't
really
be
frequent
for
a
few
reasons.
These
these
auctions,
you
can't
have
frequent
sequencer
turnover,
the
main
reason
being
that
we
sort
of
at
any
given
point
have
to
know
who
the
sequencer
is,
so
that
it
can
give
these
fast
transactions
right.
Otherwise,
again
it
sort
of
defeats
the
whole
purpose.
So
imagine
on
the
order
of
maybe
hours,
maybe
days,
I,
don't
know
we
hold
these
auctions,
so
I'll
talk
about
why
you
know
myself.
I'll
just
speak
for
myself,
but
generally
I'll
set
that
you
know
at
off-chan.
T
Labs
are
sort
of
resistant
to
this
design
space.
If
you
know
if
it
depends,
because
it
depends
on
the
ability
to
order
transactions
and
extract
Mev.
This
is
sort
of
inherently
at
odds
with
the
other
thing
that
we
want
sequencers
to
do,
which
is
give
low
latency.
Simply
because,
if
you're,
you
know,
you
need
some
time
to
figure
out
the
optimal
order
of
transactions
to
extract
value
from
them.
So
there's
some
tension
there
in
practice.
Maybe
that
won't
matter.
T
Maybe
they
only
need
a
few
extra
seconds,
but
It's,
not
nothing
right
and
again.
The
way
the
way
I
kind
of
see
it
latency
is
is
the
name
of
the
game
with
sequencer.
So
so
that's
one
thing,
because
these
auctions
sort
of
have
to
be
infrequent
like
I,
said
and
they're.
You
know
you
have
this
temporary
centralization.
There's
some
concerns
about.
You
know
some
random
party
coming
in
and
censoring
transactions
griefing
them
right.
T
The
other
practical,
the
thing
that
we
would
probably
expect
is
that
you
know
there'll
be
a
single
party
that
just
keeps
winning
the
auction
again
and
again.
Simply
because
you
know
some,
you
know
whoever
sort
of
best
optimizes
for
this.
You
know
there
will
be
some
party
who
does
that
right,
so
it's
open,
but
but
you
might
get
a
sort
of
practical
centralization.
T
But
again
the
sort
of
the
bigger
thing
is:
is
this
question
of?
Are
we
really
comfortable
with
leaning
into
the
idea
of
extracting
Envy
or
introducing
new
parties
that
have
the
same
Media
power
versus
minimizing
it?
So
real
I'll
try
to
just
get
this
in
before
I
stop
because
I
know
we're
almost
done,
but
I
want
to
talk
a
bit
about
sort
of
where
our
heads
at
at
off-gen
Labs
in
terms
of
decentralizing,
the
sequencer.
So
the
model
here
these
this
sort
of
fair
ordering
model.
T
And
these
in
order
to
give
a
receipt,
they
have
to
come
to
consensus,
a
sort
of
sort
of
like
a
bft
style
consensus,
but
it
has
this
special
property,
which
is
the
ordering
of
transactions,
is
sort
of
enforced
within
the
consensus
itself.
T
So,
unlike
you
know,
a
lot
of
bft
leader
selection,
algorithms,
where
there's
a
leaders
chosen
in
that
party
kind
of
has
full
control
over
what
to
propose
in
this
case
that
control
is
distributed
and
we
we
enforce
Fair
ordering
what
we
mean
by
Fair,
ordering
it's
a
little
hard
to
formalize.
T
But
it's
something
like
you
know:
you
have
transaction
A
and
B,
and
if
a
super
majority
of
sequencers
kind
of
witnessed
transaction
a
coming
before
transaction
B,
then
as
long
as
the
super
majority
is
honest,
that
will
also
be
the
result
so
and
yeah
some
nice
research
has
been
done.
Some
nice
progress
has
been
made
into
sort
of
improving
the
style
of
algorithm.
The
initial
ones
were
just
practically
required.
A
lot
of
network
level
communication,
so
they
weren't
usable,
but
the
latest.
T
This
thing
called
CMS,
is
kind
of
the
a
nice
breakthrough
which
makes
it
viable.
So
this
does
introduce
an
honesty
assumption.
We
have
a
fixed
set
of
parties
where
we're
assuming
an
honest
super
majority.
T
Again
any
sequence
or
solution
is
going
to
have
some
centralization
in
it
again
truly
be
open,
but
that
is
a
definite
downside.
The
more
interesting
downside
here-
and
this
is
some
of
the
pushback
that
we
got-
has
to
do
with.
T
Okay,
we've
taken
power
away
from
sequencers,
but
now,
if
you're
a
power
user
who's
trying
to
extract
Mev,
what
sort
of
what
role
does
this
create
for
you,
and
what
are
you
capable
of
doing
so,
just
because
okay,
so
we
have
Fair
ordering
there's
still
this
question
of
what
exactly
is
the
ordering
that
we're
enforcing?
T
And
initially
we
were
thinking
fifo
first
in
first
out
right,
the
order
that
the
sequencer
sees
them
is
the
order
that
they
that
they
sort
of
give
the
receipts
and
publish
transactions,
which
is
which
is
what
the
centralized
sequencer
does
now.
If
you
trust
me
the
the
issue
here
is
now,
you
can
imagine
a
power
user
who
sees
an
Arbitrage
opportunity
or
something
if
they
want
to
get
there.
T
First
now
they're
incentivized,
to
have
like
direct
Network
level,
access
to
the
sequencers,
like
literally
set
up
servers
geographically
close
to
the
sequencers
and
have
fancy
Hardware,
so
they
can
communicate
clearly,
which
is
which
is
sort
of
all
exogenous
to
the
system.
It's
it's
not
really
something
we
want
to
incentivize
it's
it's
sort
of
benefiting
users
in
this
weird
way
and
probably
a
pull
towards
centralization,
because
someone
will
optimize
that
best.
So
we
can
do
better.
So
this
idea,
the
top
of
the
slide,
is
cut
off.
T
But
very
recently
we
got
this
proposal
from
some
of
the
folks
at
at
flashbots,
particularly
Shin
AKA.
I.
Guess
sexy
sun
is
how
you
pronounce
it,
but
the
idea
here
is:
we
have
a
sort
of
hybrid
ordering
policy,
so
we
can
keep
our
Fair
ordering
algorithm,
but
we
don't
enforce
the
fairness
at
the
transaction
level.
We
enforce
it
in
these
sort
of
chunks
of
time.
We
can
imagine
discrete
intervals
of
like
half
a
second
I.
Think
that's
the
wrap
it
up
music
anyway.
This
is
a
really
interesting
topic.
T
T
C
B
B
C
B
B
B
B
B
C
All
right
cool
it's
time
for
the
panel
to
get
started.
Please
welcome
Spencer,
who
is
going
to
moderate
the
panel
and
he's
going
to
walk
from
the
back
of
the
wall
to
make
a
dramatic
entrance
soon.
U
We
love
you
all
right,
guys,
hey
everyone,
so
we're
here
to
talk
what
web3
projects
need
to
know
about
web
2,
cyber
security
and
really
I
think
this
is
going
to
be
a
great
kind
of
follow-on.
Talk
to
the
bridge
security
framework.
Talk
that
Patrick
just
gave.
This
is
kind
of
the
compliment
right,
so
he
went
over
really
some
of
the
smart
contract
and
protocol
layer
aspects
of
bridge
security.
Unfortunately,
a
lot
of
bridges
have
been
hacked,
though
not
from
you
know
the
hardcore
cryptography,
but
from
Basics
from
cyber
security,
Basics.
U
Okay,
the
cyber
security
Basics
matter
they
matter
because
they
have
geopolitical
significance.
So
before
we
get
started
on
the
panel,
take
a
look
on
the
screen.
There
was
a
great
article
by
CNET
that
came
out
a
couple
days
ago
and
it
really
talked
about
how
Lazarus
Lazarus
Group,
which
is
affiliated
with
North
Korea,
is
seeking
to
infiltrate
this
ecosystem
by
setting
up
front
companies
and
then
having
applicants.
Job
applicants
apply
to
these
front
companies
and
then
the
engineers
get
fished
right.
That's
actually
how
the
Ronin
Bridge
attack
happened.
U
U
Okay.
So
what
do
we
need
to
take
away
from
this
panel?
So
a
lot
of
fundamentals
from
the
last
two
to
three
decades
of
web
2.
Cyber
security,
there's
Cloud
security
risks
that
we
have
to
understand
and
mitigate,
coupled
with
that
there's
front-end
security
risks
right,
there's
operational
security
risks,
there's
also
corporate
security
risks
and
then
obviously,
big
topic
with
some
of
these
Bridge
hacks
has
been
Key,
Management,
endpoint
detection
and
response
and
again
management
of
individual,
individual
nodes
and
validators
doesn't
mean
we
need
to
Discount
smart
contract
security
risk.
U
What
it
means,
though,
is
we
need
to
shift
the
security
conversation
in
this
space
from
very
siled.
You
know:
individual
audits
to
a
holistic,
end-to-end
scope
of
the
Project's
entire
architecture
right
and
not
just
their
technical
architecture,
but
the
people
architecture,
and
that's
something
that
you
know.
We
have
some
newer
entrepreneurs
in
the
space
and
that's
something
that,
as
we
kind
of
get
some
Battle
Scars
as
an
ecosystem,
I
think
we're
going
to
learn
time
and
time
again.
Okay,
so
who
are
the
panelists
we'll
start
left
to
right?
U
We
got
I,
guess
we'll
start
over
there
and
the
scene
from
a16z
crypto.
We
have
Taylor
from
from
metamask.
We
have
Corey
from
openc
special
guest
Hudson
from
crypto
Twitter
and
then
another
special
guest.
We
need
from
also
from
crypto
Twitter
oops,
not
polygon,
polygon,
says
cool.
U
All
right
guys
so
we'll
start
with
kind
of
a
basic
question
and
I'll
ask
it
to
nods
first
and
then
the
rest
of
the
panel.
Now,
if
you
could
kind
of
describe,
you
know
from
the
context
of
just
normal
web
free
or,
like
a
you,
know,
representative
web
3
project
in
the
ecosystem.
What
are
the
web
two
parts
of
other
Tech
stack
and
then
what
are
the
web?
Three
parts
of
the
of
the
tech
stack
and
then
what
are
the
security
relevant
parts
of
of
each
yeah.
V
I
actually
feel
like
it's
a
it's,
a
fairly
long
answer
that
is
required
for
that,
but
you
know
we.
We
do
spend
kind
of
quite
a
bit
of
time
going
from
the
early
days
of
the
company
up
until
kind
of
like
the
ongoing
updates
to
you
know,
decentralized
protocols.
V
I
would
say
that
you
know
it
kind
of
like
starts
with
the
people.
It's
essentially
just
like
a
set
of
people
who
just
want
to
you
know
design
a
component
build
it,
deploy
it
make
it
available
and
just
like,
maintain
it
over
time.
So
there
is
kind
of
like
the
everything
that
it
that
it
encompasses.
V
So
that
means
you
know
you
essentially
start
introducing
devices
to
build
the
components
on
you
start
in
involving
kind
of
like
the
entire
kind
of,
like
you
know,
secure
software
development
life
cycle
that
is
relevant
to
every
single
person,
kind
of
like
Building
Technology
in
general
and
I'm
trying
to
cover
cover,
like
anything
that
is,
you
know,
kind
of
common
to
what
to
enter
through
here.
So
you're
gonna
have
like
this
part,
then
you
know
this.
V
These
people
need
to
build
an
organization
right
and
like
with
that
column,
you
know
kind
of
like
corporate
security.
As
you,
as
you
mentioned
earlier,
it
can
apply
anything.
You
know
from
like
a
endpoint,
you
know
security
standpoint,
device,
security
and
and
so
on.
V
I
would
say
that,
like
the
abstract
is
also
like
very
very
similar,
you
know
always
kind
of,
like
you
know,
analysis
of
your
code
as
you
kind
of
like
develop
it,
and,
and
obviously
you
want
to
iterate
pretty
fast,
so
you're
gonna
build
your
CI.
You
were
going
to
integrate
you're
gonna
run.
You
know,
security,
testing
and
Bone
scanning
and
all
the
the
stuff
that
we
all
know
in
love
doesn't
really
matter
whether
you're
building
for
web
2
or
3.
V
At
this
point
right,
I
think
that
yeah
like
in
my
in
my
mind,
everything
that
that
spans
over
you
know,
network
security,
essentially
like
network
security,
corporate
security,
appsec
security,
engineering,
key
management
and
by
the
way
like
the
key
management,
is
the
part
that
is
like
highly
overlooked.
Like
a
lot
of
people.
Think
like
okay,
it's
okay,
I
can
deal
with
this
later.
You
know
I'm
just
gonna
have,
like
you
know
like
a
single
key
on
like
either
letter
or
like
some.
You
know
a
fairly,
not
robust.
V
But
you
know,
Key
Management
is
like
a
fairly
complex
thing
that,
like
we
have
to
deal
with
in
in
web
2.,
yeah
I
would
think
I
would
say
that,
like
these
are
probably
like
the
the
the
majority
of
the
things
that
we
see
and
obviously
you
know
comes
with,
like
you
know,
physical
security
I
think
that,
like
it
kind
of
like
ties
into
you,
know
key
management
and
the
security
of
the
people
as
well,
because
it's
not
just
about
the
phones.
U
It's
also
on
that
note:
we've
heard
stories
of
people
walking
around
certain
places
with
you
know:
crypto
swag
and
exactly
having
their
phones
out
and
so
on.
So
that
probably
ties
into
this
exactly
as
well.
V
Right
yeah
and
we
had
like
quite
a
few
conversations
actually
with
you,
know
various
teams
of
our
portfolio
that
were
coming
here
and
you
know,
because
decentralization
is
a
spectrum
and,
like
you,
try
to
kind
of,
like
start,
obviously
centralized
with,
like
just
very
few
people
and
kind
of
like
you
know,
centralize
over
time.
V
There
is
like
a
point
in
time,
and
we're
probably
at
this
point
in
time
like
right
now,
where
any
person
that
kind
of
gets
hacked
attacked
like
physically,
can
kind
of
like
result
in
either
assets
getting
in
trouble
or
even
like
reputational.
You
know
damages
that
can
be
created
as
well.
V
Physical
actions,
company
or
exact
protocol,
and
so
I
think
this,
but
yeah
the
repetitional
damage
is
actually
something
that
like
is,
is
highly
overlooked
as
well.
It's
not
just
about
your
protocol.
It's
like
you,
know
everything
that
comes
around
that.
Do
you
guys
have
your
stuff
squared
away
or
not
effectively,.
W
So
when
I
think
about
web2
versus
web3
security,
especially
right
now
how
early
we
are
with
web3
and
ethereum
and
blockchain,
there
is
going
to
be
a
need
for
web
2
stuff
in
your
stack,
not
even
consumer
facing
necessarily
but
like
who
here
actually
like,
doesn't
run
their
project
on
GitHub
and
uses
something
like
matter
most
instead
of
Discord
or
slack
or
other
non-hosted
you're
awesome,
whoever
that
one
guy
in
the
back
is
but
yeah
yeah
good
for
you.
W
Something
else
is
that
I
think
is
overlooked
a
lot,
but
especially
when,
with
web
3
and
how
open
it
is
and
how
open
it
is
to
contribute,
are
two
things
watching
your
GitHub
to
make
sure
that
the
you
know,
PRS
that
are
being
put
in
are
actually
from
your
team
members,
that
you
trust
and
that
you've
vetted
Sushi
swap
had
a
bad
incident
where
someone
joined
their
join
their
team
and
then
put
something
in
that
like
I,
think
stole
keys
or
something
on
their
web.
Page.
W
Yeah
Insider
threat,
basically,
and
then.
Secondly,
this
is
something
I
worked
at
the
ethereum
foundation
as
the
org
security
lead
for
three
years
and
and
something
I
learned,
especially
as
I
was
leaving
and
hadn't
reflected
back
on.
There
were
just
a
handful,
maybe
two
people
in
the
organization
that
had
Master
access
to
just
about
everything
and
that's
incredibly
bad.
It's
even
it
was
even
worse
earlier,
so
just
bear.
U
W
Yeah,
so
the
thing
is:
if
it
wasn't
that
we
just
really
liked
and
trusted
the
people
doing
it
like
we
got
lucky,
but
really
there
should
be
different
ways
and
there's
you
can
look
up
ways
that,
like
people
have
theorized
how
to
do
this
best
for
years
separate
the
people
who
have
access
to
the
most
critical
parts
of
your
organization
and
have
an
audit
Trail
have
like
a
foolproof
audit
Trail.
They
cannot
wipe
and
so
yeah.
W
X
That
happened
a
while
back,
so
what
happened?
Actually
was
one
of
the
contractors
had
push
access
to
the
code
base.
There
was
no
PR
review
approval
process
and
it
just
got
they
like
got
angry
with
something
post,
malicious
code.
Nobody
noticed
it
got
pushed
out
and
the
key
takeaway
from
that
is.
You
should
always
manage
access.
People
should
only
have
access
to
things
that
they
really
need
in
a
production
environment.
X
No
single
person
should
have
Push
access;
it
should
always
be
approval
based
have
at
least
one
or
two
reviews
required
and
expanding
that
further,
really
like
just
minimize
access
to
only
things.
People
really
need,
for
example,
like
archers,
should
not
be
considered
as
like
a
pride
or
something
so
co-founders,
for
example,
or
founders
of
a
company
shouldn't
really
have
access
to
critical
things
like
your
emails
servers
or
whatever,
unless
they
are
actually
doing
something
of
it,
just
because
they
have
a
higher
precedence
or
whatever
doesn't
mean
they
should
have
access.
X
So
a
practical
example
in
the
Iranian
case,
the
bridge
hack,
their
employee
got
compromised
that
that
I
can
understand
like
if
someone
a
fishing
attack
he
was
like
it
was
a
very
well
orchestrated
attack,
so
I'll
give
it
to
him
like
okay
sure
he
got
caught,
but
the
issue
there
main
issue
was
that
that
one
single
employee
had
access
to
everything
like
that.
One
single
employees
access
could
have
trained,
600
million,
which
should
not
have
happened
in
production.
That
was
that
that
was
the
key
problem
in
that
hack.
Not
that
deficient
happened.
F
Y
Ahead
right
so
I'll
just
add
that
I
think
if
you
want
to
look
at
the
different
what's
missing
in
the
web,
three
on
versus
web
2
is
just
look
at
the
web.
2
Security
Org
chart.
You
know
you
have
your
instant
response
teams,
you
have
your!
You
have
a
corpse
set
group.
You
have
a
production,
Center
group,
you
have
an
app
set
group,
you
have
your
secured
reviewers.
You
have
your
vendor
security
audits.
You
have
your.
You
know.
Y
U
That's
an
interesting
question,
then,
so
in
the
various
life's
lifestyle,
like
life
phases
of
a
crypto
project,
what
needs
to
be
internal
versus
external
right,
so
obviously
everyone
goes
out
gets
an
audit.
It's
kind
of
a
commonplace
thing.
I
still
have
audits,
right,
I'm,
the
co-founder
of
a
auditing
Marketplace.
So
we
love
audits,
but
it's
not
the
the
pansia,
so
I
guess
core
to
you.
First
and
the
rest
of
the
panel
like.
When
do
you
need
to
hire
an
internal
Sizzle,
we're
starting
to
see
later
stage
projects
higher
Sizzle?
U
Y
Well,
I
have
a
bias
that,
yes,
that
played
maybe
playing
two
actually,
but
you
know
I,
think
I
think
an
under
underappreciated
property
of
security
is
that
it's.
It
is
not
something
that's
added
on
later.
It
is
an
emergent
property
of
your
design,
and
so,
if
you
don't
start
from
the
beginning,
thinking
about
security
you're
not
going
to
have
security
at
the
end
and
I.
Think
that,
like
so
yes
I
would
I
would
argue
that
you
should
have
them
early.
Z
Sorry,
yes,
I
would
like
100
agree
with
that,
because
security
is
really
about
like
the
whole
system
and
it's
like
the
social
system.
It's
the
people
system.
It's
it's!
How
you
interact
with
your
community,
it's
how
you
hire
it's,
who
you
hire
it's,
how
you
vet
them.
Z
It
literally
touches
like
everything
that
you
do
and
if
any
one
piece
is
like
not
secure.
That's
an
entry
point
and
the
thing
about
specifically
like
these
crazy
hacking
groups
that
are
coming
out
of
North,
Korea
and
other
locations
is
that
let's
say
that
they
just
get
access
to
your
slack
right.
So
it's
like
your
internal
slack.
You
got
like
20
employees
right.
Z
The
way
it's
super
crazy
and
they
will
use
the
information
they
glean
there
to
then
like
escalate
to
fish
you
Spearfish
U,
via
email
or
Spirit
issue
via
telegram
or
LinkedIn
DMS
or
whatever
they,
whatever
you
use,
they're
gonna
get
you
and,
and
they
just
over
the
course
of
like
months
and
even
years,
they'll,
just
like
keep
going
and
going
going,
and
so
it's
like
these
little
things
that
we
don't
take
seriously
because
you
don't
have
anyone
on
your
team
early.
U
Z
Z
Z
They
will
help
design
that
from
the
get-go
and
therefore
every
layer
of
your
stack
as
it
gets
bigger
as
the
responsibility
gets
spread
out
across
more
people,
as
you
scale
up
as
the
financial
incentives
get
greater
you're
just
going
to
be
in
a
way
better
position
and
I
really
cannot
emphasize
enough
like
what
Corey
said
like
you
cannot
add
Security
on
after,
like
it's
not
a
thing,
you
can't
be
like
oh
yeah,
we'll
just
be
lazy
now
and
then
we'll
like
fix
it
later.
F
F
U
X
Know
yeah,
but
like
just
being
practical,
if
you
are
just
starting
out
I,
don't
think
a
second
employee
needs
to
be
the
security
guy.
But
what
needs
to
happen
is
your
first
developer
needs
to
have
a
security
mindset.
Your
first
IIT
hire
that
will
probably
happen
when
you
are
10
to
25
people.
That
needs
to
have
some
security
background.
How.
X
Security
mindset
when
you're
high-
so
that's
a
great
question.
Yes,
it's
not
something
I
can
like
like
Define
qualities
or
something,
but
if
you
like
for
me,
if
I
look
at
someone's
code
the
way
they
are
writing
it,
the
way
they
are
documenting
it.
I
can
tell
like
it's
just
intuitive
that
this
guy
is
thinking
about
security.
X
If
you
just
talk
to
someone
like
look,
ask
them
their
priorities,
see
how
well
tested
their
code
is
even
the
code,
syntax
and
everything
it
will
tell
you
how
serious
they
are
about
security,
so
yeah.
Your
first
developer
have
someone
with
a
security
mindset.
Let
them
train
others,
then
your
it.
Guy
probably
will
be
your
next
get
someone
with
prior
security
experience,
but
does
it
need
to
be
a
dedicated
security
people
and
then,
when
you
scale
Beyond,
maybe
20
people?
X
That's
when
you
should
start
looking
into
a
dedicated
security
person
for
your
role
before
that.
Just
have
internal
people
with
security
mindset,
plus
hiring
or
not
hiring,
but
like
just
Contracting
external
service
companies
to
provide
you
with
security
help
external
companies.
They
don't
only
do
audits.
They
will
help
you
with
internal
security.
As
well,
because
the
thing
is,
if
your
org
is
below
20
people,
the
security
guy
won't
really
be
utilized
fully.
X
Unless
you
are
someone
like
FTX
with
like
10
10x
Engineers,
that's
pushing
the
whole
code
out,
then
it's
a
different
story,
but
talking
about
normal
logs
yeah
security,
people
can
come
in
a
bit
late.
U
Z
Just
want
to
chime
in
on
that
that
the
point
that
you
made
about
like
the
security
mindset
like
what
is
the
security
mindset,
I,
think
one
reason
why
web3
sort
of
struggles
with
this
security
mindset
a
lot
of
times
is
that
we
are
like
so
generally
optimistic
and
like
Visionary
and
forward
thinking,
and
we
are
thinking
about
the
potential
and
we
are
like
thinking
that
nothing
is
impossible,
and
so
so
much
of
our
time
is
spent
in
this
sort
of
idealistic
future
world
that
we're
trying
to
build
and
that's
necessary,
like
we
have
to
be
that
in
order
to
build
these
crazy
things
that
we're
building,
however,
like
I,
would
say
that
I
have
a
security
mindset,
but
I
would
also
say
that
I
don't
spend
most
of
my
time.
Z
U
So
that's
like
the
security
mindset
on
that
note,
how
do
you
ensure
compliance,
then
right,
I
think
it's
something
we
had
talked
about
before
is
like
getting
people
to
actually
do
the
fundamentals,
even
simple
things
like
MFA
being
enabled
right
or
Corey
would
talk
about
this.
You
know
endpoint
detection
and
response
actually
being
used,
and
if
people
aren't
using
that,
then
you
kick
them
off
the
network.
How
do
you,
how
do
you
get
people
to
actually
do
the
basics
so.
Z
Like
when
we
were
starting
up
right
like
and
I
I,
Grew,
From,
Me
and
My
co-founder
to
20,
and
now
we've
got
like
sort
of
over
100
on
the
core
team.
We
got
like
there's
a
thousand
at
consensus
right
now,
it's
a
when
we
had
like
two
people,
three
people
and
started
bringing
people
on
the
thing
that
we
did
from
the
gecko
was
we.
We
had
good
documentation
about
like
what
was
required
and
what
was
expected
of
our
employees.
Z
It
talked
about
like
what
they
needed
to
do
and
it
need
they
needed
to
do
it
across,
like
all
of
their
accounts,
like
there's
no
personal,
professional
split
in
crypto.
So,
like
you
have
your
personal
Twitter
like
that
needs
to
be
security.
If
you're
going
to
be
a
part
of
our
company,
the
other
thing
is
a
lot
of
these
services
like
GitHub.
You
can
force
like
if
you
want
to
be
a
contributor
to
my
repo,
like
you
have
to
have
your
MFA
on.
Z
We
bought
everyone,
multiple,
like
all
the
Little
Hardware
doodads
right.
Everyone
has
a
ledger.
Everyone
has
a
tresler.
Everyone
has
all
all
of
them:
the
Google
ones,
the
the
the
yeah,
the
Yuba
keys
and
the
Google
one,
the
Titan
one.
Z
F
Z
Was
that
one
was
pretty
slick,
still
go
back
to
my
ubiki
all
the
time,
though,
and
these
things
right
from
the
get-go
like
like
the
first
employees,
no
matter
what,
then,
as
you
grow,
you
like
your
procedures,
are
sort
of
in
place,
but
then
your
early
employees
also
like
established
this
like
floor
of
like
this
is
what's
expected
right
and
and
that's
the
culture
like
that's
how
you
establish
the
culture
like
nobody
is
going
to
step
out
of
line
when
it's
already
there
right
and,
and
you
call
each
other
out
like
when
you
see
someone
being
a
little
bit
lazy.
U
U
B
V
Like
the
like,
the
First
Security,
people
that
need
to
be
hired
are
like
literally
the
founders
because,
like
I
mean
they
need
to
have
like
this
adversarial
mindset
like
from
the
get-go,
as
many
was
saying,
it's
like
I
feel,
like
almost
like
web
2
versus
web3,
is
kind
of
like
the
wrong
kind
of
like
comparison,
because,
like
we're
really
in
just
the
the
business
of
security,
critical
software,
we
had
this
conversation
yesterday
with
Corey.
It's
like
you
know.
V
V
Right
like
it's,
always
the
the
security,
it
doesn't
live
kind
of
like
on
its
own
right,
like
in
a
corner.
It
actually
always
is
a
balance
between.
You
know
convenience,
like
you
know,
product
features
and,
like
user
experience
versus
you
know
the
safety
of
of
doing
these
actions.
So
I
think
that,
like
just
just
having
the
founders
kind
of
like
come
with,
this
mindset
like
right
away,
is
the
most
important
thing.
V
I
think
that,
like
we,
don't
want
to
be
too
prescriptive
about,
like
the
mindset
that
people
have
before
before
initially
like
investment,
but
it's
more
like
as
soon
as
like
we
meet
with
them.
We
kind
of
like
do
the
rundown
of
everything
and
we
kind
of
like
provide.
You
know
insight
into
all
the
threads
that
they're
exposed
to
and
kind
of
like
try
to
really
if
they
don't
have
it
already
like.
V
This
mindset
just
make
sure
that,
like
after
a
discounted,
the
first
conversation
they're
already
kind
of
like
think
about,
like
everything
that
that
is
going
to
go
wrong,
because
it's
only
a
matter
of
time
right
that
you
were
saying
it's
like
it's
a
matter
of
price
and
time.
Essentially,
so
that's
that's
like
how
we
how
we
approach
this
interesting.
U
X
Exactly
so,
that's
one
thing:
this
ecosystem
needs
to
understand
that,
at
the
end
of
the
day,
security
is
really
about
users,
even
if
your
protocol
is
secure,
but
nobody
knows
how
to
properly
use
it
and
everyone
just
keeps
getting
compromised.
Then
you
have
failed,
like
you
create,
like
you,
use
the
public
private
key
architecture,
but
you
never
tell
anyone
how
to
secure
their
private
key
everyone
just
copy
paste
that
on
Google
everyone
gets
compromised.
You
have
failed
your
mission,
so
user
education
is
super.
X
Important
metamask
here
is
doing
a
great
job
at
it,
but
we
need
a
lot
more
of
it
and
to
get
yeah
and
to
get
that
like.
We
need
to
really
understand
like
in
this
space.
We
need
to
understand
one
thing
that
it
is
not
always
about
getting
the
like
getting
your
mindset
very
crypto,
focused
or
whatnot.
You
can
be
a
crypto
Anarchist,
but
you
have
to
be
practical
in
the
sense
stop
telling
like
60
or
60
year
old
grandmas
to
manage
their
own
keys.
X
They
are
much
better
off
using
a
custodial
Service,
not
your
keys,
not
your
coins,
everyone's
favorite
logo,
but
if
you
don't
know
how
to
manage
your
private
Keys
doesn't
matter.
If
your
key
is
yours
or
not,
it
will
just
get
compromised.
X
So
unless
you
know
what
you're
doing
it's
often
better
to
just
go
with
a
service
product
just
a
custodial
product,
rather
than
trying
to
learn
what
you
don't
know,
this
is
why,
even
in
traditional
Finance
like
earlier
in
the
days
you
saw
like
bonds
and
everything
were
paper-based,
but
eventually
everything
got
digitized
and
everyone
just
uses
a
custodian.
X
Nobody
really
ever
buys
shares
on
anything
directly
anymore.
Wherever
you
go,
you
are
buying
them
through
a
platform
through
a
custodial
platform,
because
Trad
fire
has
understand
that
it's
it's
not
ex
like.
If
you
want
to
scale,
you
can't
ask
everyone
to
just
manage
their
own
keys
or
secure
their
whole
things.
You
have
to
make
it
much
easier,
but
what
we
in
web
3,
what
we
need
to
do
is
give
users
the
choice.
X
So
if
someone
is
tech
savvy
enough,
if
they
want
to
run
their
own
node,
if
they
want
to
manage
their
own
Keys,
they
should
be
able
to
do
that.
But
we
shouldn't
be
like
shaming
others
for
using
infuro
or
other
products
or
like
using
custodial
products.
We
just
have
to
change
that
mindset
and
educate
people
on
both
ends.
Y
I,
so
one
thing
I
would
add
to
the
ux
which
100
it's
it's.
The
ux
is
such
a
big
part
of
security
and
helping
people
do
the
right
thing,
but
I
think
an
unappreciated
part
of
it.
Ux
is.
Is
that
it's
actually
a
you
know
it's
a
team
game.
It's
it's
every
one
of
us
in
this
room
every
product,
every
project
that
works
in
web3,
the
the
the
ux
is
not
just
how
good
your
ux
is
it's.
Y
How
consistent
is
your
ux
with
everyone
else?
You
know
the
way,
users
the
way
they
learn.
What
is
safe.
What
is
unsafe
is
consistency
when
they,
otherwise
they
have
no
prayer
of
going
on
to
a
website
and
knowing
if
this
is
going
to
scam
them
or
not,
because
they're
gonna
have
a
whole
new
ux
and
every
single
time,
and
maybe
this
website
just
does
a
little
bit
differently
and
they
have
no
way
of
telling
just
you
know
using
your.
Y
You
know
your
lizard
brain
on
in
fact
right
when
you're
on
that
website,
what
your,
what
you
should
or
shouldn't
be
doing.
You
know
I.
My
favorite
example
of
this
is
logging
in
you
know,
on
a
d
app,
you
connect
your
wallet
and
you
know
some
websites
change
and,
like
start
start,
treating
giving
you
data
about,
like
you
know,
what's
associated
with
your
wallet,
some
don't
yet
or
they'll
immediately
challenge
you
some
will.
Y
Let
you
click
around
and
then
you
then
challenge
you
and
you
don't
you
don't
have
this
concept
of,
like
am
I
authenticated
or
am
I
not
like
how
like
where?
Where
is
that?
What
is
it?
What
is
expected
of
me
and
all
of
a
sudden,
you
click
something
you
just
pop
up
asking
you
to
sign
something,
and
you
know
who
knows
what
that
something
is.
Hopefully
it's
science
ethereum,
but
you
know-
and
you
know,
compare
that
Tool
passwords.
Y
You
know
users
have
three
decades
of
experience
with
passwords
and
knowing
how
to
log
into
a
website.
It's
consider
every
website's
exactly
the
same.
They
they
know
exactly
what
the
experience
is.
They
know
where
they
know
what
an
authenticated
state
is
versus.
Unthane
State,
like
that,
is
you
you
we're
com,
we're
in
Ground
Zero
with
user
education,
and
it's
not
just
how
good
your
product
is.
Y
W
If
you
want
to
look
at
good
user
documentation
and
education
around
every
little
thing,
go
to
my
cryptos
facts
and
their
like
documentation,
it's
so
good
because
it
like
will
walk
you
through,
like
the
mempool
it'll,
walk
you
through
what
a
private
key
is
and
all
these
other
websites
that
are
built
on
ethereum,
assume
prior
Define
knowledge
assume
prior
Key,
Management
knowledge
and,
if
you're,
really
building
for
people
outside
of
the
ecosystem
and
including
other
crypto
ecosystems
that
have
dissimilar
key
structures,
and
things
like
that.
W
You
should
really
spend
just
a
little
bit
of
time,
invest
in
a
tech,
Rider
and
or
even
just
point
to
other
people's
pages
that
give
that
education
for
the
users
and
like,
if
that
sign
like
sign
this
message.
Box
pops
up
I
mean
there's
so
many
people
who
don't
realize
that
doesn't
cost
money.
That
is
not
a
transaction
that
is
signing
a
message
from
your
public
from
your
keys.
Keep
here
so
like
we're
just
so
far
behind.
W
In
that,
because
the
protocol
layer
can't
be
the
ones
to
teach
that
users
aren't
running
CLI,
Geth
and
learning
that
from
scratch
anymore.
That's
where
I
learned
it,
but
that
was
way
long
ago,
where
it's
very
different
now
so
yeah
just
look
at
really
good
documentation
and
try
to
emulate
that
in
your
project,.
Z
Yeah
I
want
to
emphasize
like
the
amount
of
docs
that
I've
written,
but
it's
worth
it
because
you
will
be
surprised
at
like
how
much
people
want
to
learn
and
so,
like
there's
sort
of
like
this
track,
where
like
we,
can
make
the
ux
better
and
we
could
give
users
more
choices
that
better
serve
them
like.
We
should
definitely
do
all
of
those
things.
Z
But
if
something
is
like
the
current
way
of
doing
it-
and
it's
not
clear-
and
it's
not
obvious-
take
that
opportunity
to
tell
the
user
just
like
literally
tell
them-
don't
treat
them
like
they're
idiots
right
treat
them
like
they're,
smart,
capable
adults
and
tell
them
what's
happening
because
they
will
carry
that
knowledge
and
then
they
will
actually
pass
that
knowledge
along
to
other
people.
And
it's
it's
quite
remarkable.
Z
You
would
think
like
the
docs
I've
written
like
what
what
what
comes
with
that
nobody
reads:
docs
like
it's
weird,
when
my
words
like
show
up
in
other
people's,
like
Tweets
in
other
people's
documents,
right
people,
reference
myself
like
I'm,
like
wow.
There's
people
really
reading
this.
It's
it's
amazing.
I
also
want
to
say,
like
back
to
what
Corey
was
talking
about.
We
do
need
to
work
together.
Better
I'm
told
nadav
is
in
the
audience,
love
you
nadab.
The
dog
called
us
out
recently
like
now.
Z
Open
Sea
called
metamaskow
because
there
is
so
much
use
or
loss
happening
right
now,
and
a
lot
of
the
user
loss
is
actually
literally
with
users
of
openc
who
are
using
metamask,
and
we
should
be
working
together
better
to
make
sure
that
every
single
thing
that
we're
doing
and
showing
the
users
is
way
clearer
and
we
should
be
in
lockstep
so
that
when
openc
releases,
a
new
sighting
mechanism
or
a
new
way
of
handling
something
metamask
can
actually
like.
Z
You
know
not
show
gibberish
literally
not
show
gibberish,
please
anything
but
gibberish,
and
so
we
have
some
like
exciting
things
in
the
works
that,
like,
hopefully,
we'll
we'll
get
into
production
soon,
that
that
will
ultimately
serve
not
just
metamask
users,
not
just
open
to
users.
Right
it'll
serve
everyone
in
the
ecosystem,
but
specifically
right
now.
It
will
prevent
the
loss
that
we're
seeing
and
we
are
seeing
an
immense
amount
of
loss.
U
AA
W
But
yeah
no
I
I,
you
might
be
able
to
answer
a
better
tailored,
but
all
the
groups
I've
seen
some
of
them
have
worked
really
great.
Some
of
them
floundered,
because
the
teams,
especially
the
ones
starting
out,
but
they
have
a
big
impact-
are
small.
They
don't
have
the
time
to
commit
to
going
to
a
bi-weekly,
Zoom
meeting
to
look
into
that
and
then
there's
a
lot
of
of
competing.
W
What
am
I
trying
to
say
there
was
like
for
a
while.
There
was
even
competing
ERC
standards.
You
know
a
few
years
ago
up
until
now,
with
even
the
basics
of
how
we're
doing
messaging
and
signing
of
transactions
across
a
theory.
That's
a
very
interesting
history
to
look
back
on,
but
to
fully
answer
it.
W
I
guess:
yeah,
just
pretty
much
direct
communication
with
the
teams
like
if
something's
happening,
just
telegram
them
and
then
don't
just
leave
them
for
a
few
days
like
literally
get
back
to
them
soon,
especially
if
it's
like
money,
loss,
security
related
that
kind
of
that's
where
you
need
to
have
a
dedicated
person,
who's
doing
at
least
security,
infra
or
ciso
or
whoever
who
could
be
like.
Oh,
let
me
grab
my
lead,
devil
think
this
is
in
10
minutes.
It.
U
V
Thing:
yeah,
oh
good,
okay,
one
thing
I'd
like
to
add,
is
kind
of
like
on
this
conversation.
I,
think
that,
like
we
should
learn
from
a
lot
of
the
the
great
kind
of
like
ux,
efficient
security
that,
like
that
has
been
put
out.
I
think
that,
like
apple,
is
probably
like
top.
V
You
know
like
the
the
kind
of
like
top
company
in
in
this
space
that,
like
has
been
not
in
the
species
like
in
the
tech
space
in
general,
in
terms
of
like
ux
security,
and
you
know,
if
you
take
something
as
simple,
you
know:
I
I
used
to
work
there
and
in
the
security
team
and
kind
of
like
saw
a
bit
like
the
mindset
from
like
internally,
and
you
can
see.
V
For
example,
like
you
know,
logging
in,
for
example,
like
used
to
be
like
unlocking
your
phone
used
to
be
pin-based,
and
you
know
we
all
know
that,
like
people
just
like
hate
to
remember
things,
so
what
did
people
do?
You
know
when
they
were
allowed
to
bypass
it?
They
bypassed
it
right.
It
was
kind
of
like
I,
think
for
only
14
of
the
people
used
to
have
depend
on,
and
everyone
else
had
just
like
the
fully
or
even
before
the
passwords
right
password.
V
So
you
know
it
it
like,
if
you're
thinking
about
kind
of
like
the
mechanism
to
just
like
make
security,
easy
and
just
like
flow
with
the
ux
people
will
just
like
come
along
with
you
in
the
process
and
so
I
think
that,
like
again
we're
discussing
this
with
because
yesterday
I
think
that,
like
the
the
you
know,
the
the
user
interface
can
do
a
lot
more
for
us
as
of
today.
You
know
when
we're
thinking
about
when
we're
thinking
about
making.
V
Obviously,
like
educated
decision,
you
know,
metamask
and
and
other
wallets
are
starting
to
to
put
like
great
features
in
order
to
kind
of
like
show
you,
you
know
what
are
you
essentially
achieving
by
submitting
this
transaction
to
the
network?
What
is
what
is
going
to
happen
essentially
ahead
of
time,
but
something
that
is
super
interesting
is
like.
There
is
more
to
be
done.
You
know,
like
you,
have
approvals
for
your
nfts.
These
are
permissions
right.
V
Similarly,
for,
like
your
fungible
token
allowances
that
could
be
managed
actually
directly
within
the
wallet,
the
wallet
should
be
able
to
do
that.
Just
like
your
phone
actually
manages
your
permissions.
You
know
like
giving
access
to
you
know,
cameras
and
like
Bluetooth
and
like
location
services
and
so
on.
Like
all
of
these
things
are
things
that
we
can
learn
from.
V
Just
you
know
great
user
experiences
on,
like
you
know,
mobile
devices
and
so
on
and
and
I'm
really
hopeful
that
we're
going
to
see
more
of
these
things
as
part
of
audits
and
simulated
for,
like
you,
know,
fishing
when
we
see
like
a
lot
of
people,
that
kind
of
like
get
scammed,
sign
the
wrong
like
set
approval
for
all
and
get
kind
of,
like
all
of
their
wallet,
trained,
even
kind
of
like
wallet
management
should
be
possible
like
within
the
within
the
wallet
itself.
V
Like
you
know,
think
about
you
know
your
wallet
essentially
just
like
spinning
off,
like
you
know,
generating
a
new
address
on
the
Fly.
You
know
providing
essentially
really
like
allowing
you
to
just
like
send
funds
like
minimal
amount
of
funds
to
just
like
pay
for
the
gas
fees
for
the
operation
and
not
have
access
to
any
other
asset.
W
W
A
second
redefine
we
Define
yep.
U
W
Y
So
something
I
would
add
so
100
agree,
I,
think
all
that
stuff's,
amazing
and
I
think
you
know
we're
going
back
to
you
know
this
whole
thing
started
web
two
right,
I.
Think
one
of
the
things
we
can
also
take
away
from
the
web
2
world
is
like
the
depth
of
security
controls
that
have
been
implemented.
Y
You
know,
no
one
is
you
know
going
back
to
right
now
we're
kind
of
running
and
bring
zero,
and
when
you,
when
you
sign
you
sign
with
your
wallet
the
equivalent
of
an
operating
system
like
you
know,
adding
those
kind
of
controls
would
be
awesome,
ways
to
put
some
sandbox
and
some
capability
based
access
controls
and
extroduction
mechanisms.
Y
But
you
know
there's
more
to
there's
more
layers.
We
can
add
right,
I.
Think
one
of
the
biggest
areas
in
my
mind
right
now
is
and
I've
learned
this
from
talking
to
victims
of
phishing
attacks.
Is
they
don't?
They
often
don't
even
know
where
they
signed
the
malicious
transaction
at
they
they're
they're
at
a
loss
and
there's
no
introspectability
we're
missing.
Y
Y
The
user
side
yeah
we,
if
we're
going
to
trust
you
bring
them,
say
your
key,
your
your
your
Authority,
you
also,
oh,
we
also
owe
them
every
tool
they
need
to
be
able
to
do
that
correctly
and
that
blogging
and
monitoring
is
a
big
part
of
that.
Z
Yes,
specifically,
one
thing
that
we've
like
experienced
at
metamask
that
openc
has
called
us
out
on
and
continues
to
call
us
out
on
is
for
the
longest
time
there
were
transactions
and
the
transactions
have
like
Financial
value,
and
it's
pretty
easy
to,
like
you
know,
like
teach
users
like
this
is
a
thing
and
like
there
might
be
some
bad
things
that
happen
depending
on.
Z
If
you
click
this
button
and
then
now
a
lot
more
stuff
is
just
off
chain
right
or
it's
not
on
chain,
until
after
a
certain
period
of
time,
if
the
order
is
matched
or
whatever
right,
and
because
of
this,
like
super
early
assumption
that,
like
everything,
is,
there's
a
key
and
then
you
have
transactions
and
the
transactions
go
on
a
chain.
Because
of
that
super
early
assumption
that
we
made.
We
did
not
see
this
coming
we're
now,
a
like
just
a
signature
right,
just
like
an
off
change.
Z
Signature
can
actually
lose
you
like
all
of
your
nfgs
or
all
of
your
tokens
or
allow
permission
somewhere
else
right
and
so
now
we're
like
playing
catch
up
while
open
C's
like
sprinting
ahead
like
making
sure
that
it's
usable
making
things
scalable
we're
playing
catch
up
to
try
to
like
map
back
and
like
in
reality,
we
should
have
never
ever
treated
a
transaction
like
an
on-chain
transaction
signature
differently
than
a
message
signature,
and
because
of
that
very
early
design.
Choice
like
at
the
core
architecture
level.
Z
We
are
now
like
remapping
everything
and
it's
like
it's
just
a
it's
a
stupid
amount
of
work
to
be
honest,
and
it
takes
way
longer
than
it
should,
and
it's
especially
painful
when
users
are
are
losing
money
because
of
this
every
day,
right
like
when
we
are
hearing
about
celebrities
losing
their
nfts.
Because
of
this
thing
that,
like
we
know,
should
be
better.
That
is.
That's
horrible.
Z
I
also
want
to
comment
that,
like
my
talk
tomorrow,
I'm
gonna
be
diving
into
like
some
of
the
early
early
choices
of
like
wallets,
but
also
of
the
protocol
itself
and
diving
into
like
a
lot
of
the
stuff
we're
talking
about
here,
because
I
think
that
the
the
biggest
sin
of
it
all
is
that
it
all
traces
back
to
this
like
private
key
and
this
private
key,
gives
full
authority
over
everything.
Z
Z
Think
that,
like
we
are
now
seeing
that,
like,
at
the
token
level,
we're
trying
to
like
Implement
permissions
and
restrictions,
but
ideally
like
that,
would
actually
live
like
out
at
the
very
core
layer
right
where,
like
the
first
thing,
the
thing
that
holds
your
stuff
is
actually
like
a
default
like
you
don't
do
anything,
and
the
first
thing
you
have
to
do
is
Grant
the
permission,
and
then
you
can
take
the
action.
Z
So
yeah
come
to
my
talk
tomorrow,
we'll
we'll
dive
into
this,
but
you
know
I
think
that
this
is
why
I
really
want
to
emphasize
like
have
conversations
with
like
the
people
that
are
around
you
learn
from
your
users.
Listen
to
them
like
the
most
valuable
thing
that
I've
ever
done
is
have
literal
one-on-one
conversations
with
people,
who've
lost
all
their
money
and
like
just
ask
questions
and
let
them
talk,
because
you
will
learn
so
much
about
where
your
product
is
failing
and
you
will
be
able
to
serve
them
so
much
better.
Z
X
You
agree
with
that
on
on
the
bit
dot.
Private
key
search,
I
completely
agree
that
refers
back
to
the
point.
I
was
saying
like
theoretical
security
is
one
thing:
people
have
built
products
that
are
secure
in
the
best
case,
but
if
they
are
not
practically
secure,
if
nobody
knows
how
to
use
their
product,
if
nobody
knows
how
to
manage
their
keys
and
so
on
by
just
failing
at
your
goal
and
then
the
other
thing
on
monitoring
and
alerting.
X
X
Someone
literally
message
them
on
desk
or
hey
something's,
not
right
so
yeah
anyway,
you
should.
You
should
have
proper,
alerting
and
monitoring,
but
yeah
also
don't
go
too
overboard.
Don't
start
logging,
private
keys
of
users.
You
have
to
find
the
right
balance
there,
but
all
of
that
aside,
I
want
to
like
take
a
step
back
and
like
say
we
just
like.
X
Never
talk
really
talked
about
the
title,
which
is
web
2
versus
web
3
same
or
different,
because
I
think
we
all
just
assume
they
are
the
same
web3
just
sprinkles
a
few
things
on
top
of
webto
security.
But
if
it
wasn't
clear
like
at
least
in
my
opinion,
they
are
basically
the
same
things.
Spencer
here
has
been
trying
to
guide
us
towards
a
bunch
of
I,
think
20
questions
or
something
he
prepared.
If
you
have
managed
to
get
through.
Maybe
three
no
just
wait
on
one
random
spree
yeah,
but
he
has
done
a
great
job.
U
Yeah
speaking
of
a
curveball
question,
so
we
were
sharing
more
stories
outside
yeah,
there's,
a
reason
why
we're
not
going
with
the
prep
questions
so
Taylor
you're.
You
were
sharing
one
about
incident
response
because
you
know,
obviously,
after
you
do
monitoring
to
log
in
oh
crap,
something
happened
right.
Z
So
this
piece
is
decentralized
and
a
lot
of
the
teams
are
there
for
fully
remote.
We
use
telegram,
we
use
slack,
we
use
Discord,
we
use
signal.
We
use
like
there's
like
8
000
chat,
apps
I,
don't
know
about
you
but
like
for
me.
My
notifications
are
basically
like
off
because
otherwise
I'll
just
be
like
constantly
inundated
with
information
and
I,
wouldn't
be
able
to
think.
Z
However,
if
something
happens
like
how
do
you
let
that
person
know
that
something
happened
so,
for
example,
this
one
time
Hudson
was
coming
to
talk
and
you
got
Sim
swapped
while
on
stage
and
the
Sim
Stoppers
actually
talked
to
his
wife
and
I
think
told
her
that
he
was
kidnapped
because
they're,
because
they're
Sim,
swappers
and
because
me
and
husband,
have
like
a
relationship
that
goes
back
and
because
Twitter,
like
immediately
alerted
that
Hudson
was,
was
Sim
swapped.
Z
It
was
like
damning
asking
for
money
because
of
that,
like
I
had
the
actual
sort
of
like
in
real
life
Network
and
the
actual
phone
numbers
in
place
to
be
able
to
like
contact
right
same
thing
has
happened
with
my
own
team,
like
I,
don't
know
having
each
of
those
phone
numbers
and
making
like
old
school
phone
calls
that
break
through,
like
the
Do
Not
Disturb
mode
is
like
critical.
Almost
every
single,
like
incident
response
includes
like
tracking
down
the
person
who
has
the
person's
phone
number.
W
W
One
of
us,
because,
another
time,
someone
posted
something
on
my
Twitter,
because
I
had
like
an
API
key
out
there
anyways.
The
second
thing
is
when
I
got
Sim
swapped
and
as
soon
as
it
got
on
there,
I
walked
I
went
back
home
when
I
was
everything
was
fixed.
There
were
10,
very
critical
group
chats
that
just
said,
Hudson
Sim
swap
don't
listen,
anything
he
said:
Hudson
swim
stock,
don't
listen
to
anything.
He
said
and
my
startup
at
the
time
open,
Innovations
immediately
shut
out
all
my
access
cleared.
W
W
We
had
a
dedicated
CSO
role,
type
deal
that
we
have
kept
over
the
years
and
years
and
years,
and
we
have
a
great
one
right
now
who
replaced
me
after
I
left
or
not
before
I
before
I
left,
the
EF
and
I
was
doing
other
things,
but
either
way
yeah.
W
That
was
one
of
the
scariest
things
because,
like
the
cops
were
called,
my
spouse
is
crying
one
more
thing,
and
this
is
something
just
not
related
to
this
exactly,
but
something
I'm
really
proud
of
it
for
my
spouse,
wouldn't
I
finally
got
a
hold
of
her.
The
first
person
after
resetting
my
passwords
and
I,
went
to
the
like.
You
know
the
phone
store,
I
called
them
and
I
said
hey.
This
is
Hudson
and
they
were
crying
and
they
were
like
I'm
here
with
a
police
officer.
W
W
So
so
the
day
to
do
it
was
me
and
everything
worked
out
from
there.
Yeah
yeah.
Y
This
one
like
really
high
at
one
point
you
had
there,
which
well
is
like
having
the
plan
but
I,
think
a
key
is
practicing
the
plan.
Y
Tabletop
simulations
making
sure
that
what
you
know
documenting
where
the
failures
were
white,
what
was
hard
and
smoothing
it
over
before
you
actually
need
to
do
it
in
in
real
life.
Actually,
one
of
my
favorite
stories
of
this
was
we
had
a
simulation
where
we
had
to
disconnect
our
Corp
from
our
prod
Network
previous
company,
and
we
had
one
room
that
we
could
get
into,
but
that
room
kept
getting
smaller
and
smaller,
because
you
know
we
never
need
that
room
and
then,
when
we
enter
simulation
we
did.
Y
We
realized
there's
only
one
ethernet
Jack
and
we
had
no
way
of
getting
all
of
us
into
that
room,
to
be
able
to
connect
to
prod
and
to
keep
it
up,
keep
everything
up
and
then,
like
so
we're
like
yeah.
So
it's
just
one
of
those
like
there's.
It's
always
the
thing
you
don't
think
about
that.
Fails
you
in
an
incident,
and
you
want
to
know
that
before
you
actually
before
it
counts.
V
War
yeah
another
another
thing:
I
think
that,
like
is
important
to
to
take
into
account,
is
that
a
lot
about
incidents
response
and
like
Incident
Management
is
about
time
right
like
time
works
against
you,
the
person
is
you
know
someone
or
like
some
entity,
some
group
already
kind
of
like
perform
like
found
the
issue
and
kind
of
like
try
to
execute
it,
so
your
role
is
also
to
kind
of
like
expand
as
much
as
possible,
the
time
window
that
you
have
where
time
can
kind
of
work
for
you
right,
it's
kind
of
like
and,
and
you
know
we
kind
of
like
always
discuss
these
things.
V
Well,
like
you
know,
governance
protocols
and,
like
you
know,
Bridge
security,
it's
it's
about,
like
you,
know,
time
locks
and
just
like
freezing
funds
for
like
specific
amount
of
time,
so
that,
like
you,
actually
give
yourself
some
kind
of
like
breathing
rooms
and
kind
of
like
your
teams
to
kind
of
like
go
over
the
logs
go
over
like
everything
that
happened
understand
exactly
like
is
like.
Is
this
something
legit
or
not?
If
this
is
not
legit,
you
know.
V
Obviously,
if
you
have
other
mechanism
in
place,
great
otherwise
kind
of
like
get
ready
for
you
know,
kind
of
like
freezing
assets
across
you
know,
chains
and
so
on.
So
I
think
that
just
like
making
time
work
for
you
is
also
one
of
the
most
critical
things
that
you
that
you
can
do
and
a
lot
of
people
have
been
kind
of
like
theorizing
about
this.
V
V
So
that's
that's
something
that
is
very,
very
important
and
obviously
you
know
will
never
emphasize
enough
that
the
need
to
kind
of
like
you
know,
baking
time
whenever
you
have
like
a
new
governance
proposal
and
just
like,
whenever
you
have
like
specific
thresholds
or
like
limits
that
are
hit,
you
know
making
sure
that
these
things
like
take
time
and
that
you
have
like
some
some
freezing
periods
where
you
can
actually
like
cancel
operations.
Y
AB
Y
Your
systems,
you
may
you
you
make
sure
you
patch
systems
and
you
find
them
and
you've
audit
them
and
then
but
then,
whenever
things
do
happen,
you
time
box
along
the
attacker
has
in
your
systems
that
we
have.
You
can
quickly
respond
like
these
all
the
stuff
layers
and
that's
how
you
get
a
great
security
defense
in
depth
on.
X
X
Have
a
disaster
recovery
plans
literally
have
playbooks
of
every
scenario
you
can
think
of
of
anything
that
can
go
wrong,
have
playbooks
of
what
to
do
so
that,
even
if,
like
your
out
sake,
someday
and
some
other
security
or
someone
else
in
the
article
doesn't
really
know
as
much
about
the
product
can
just
see
your
playbook
follow
the
exact
steps
and
be
all
good
and
like
you
need
to
practice
these
playbooks
as
well.
It's
not
just
about
having
the
content
out
there.
X
You
need
to
practice
all
of
these
playbooks
and
everyone
should
be
aware,
like
what
needs
to
happen.
When
needs
to
happen,
how
to
follow
the
Playbook,
and
only
then
you
will
be
able
to
properly
respond
in
a
timely
fashion
and
another
bit
I
would
say
like
coming
back
to
the
swim
swap
thing.
X
So
there
I
wanted
to
add
a
little
thing
so
with
seven
swaps,
in
fact
not
just
same
swap,
but
any
product
where
the
support
department
of
the
company
can
like
do
whatever
with
your
access
or
wherever,
like
you,
don't
have
control
on
your
product,
which
is
most
of
the
webto
products,
don't
depend
on
either
get
something
like
highly
secure
or
don't
depend
on
the
cheapest
one.
X
So
for
Sims,
almost
all
of
the
public
providers
like
they
can
just
same
swap
any
of
their
support
engineer
or
whatever
can
same,
swap
you
so
never
use
mobile
numbers
for
2fa
or
recovery
or
anything
permission.
What.
U
Do
you
think
of
a
funny?
That's
the
one
supposedly
non-senswapable
cell
phone
provider,
I'm.
V
There
is
an
entry
point
right,
and
it's
like
this
is
just
like
a
matter
of
like
how
much
Social
Engineering
you
can
do
like
people
were
saying
that,
like
Google
5
was
actually
not
sim
swappable,
because
there
is
no
one
to
talk
to
on
the
customer
service,
but
you
know
it
it
could
happen.
You
know
like
no
one
is
kind
of
safe,
despite
because
even
the
more
secure
cell
phone
providers.
V
You
know
you
want
to
aim
for.
Obviously
you
know
the
regular
kind
of
like
non-isms
to
fa
base
but
like
if
you're,
if
it
is
mandatory,
go
for,
like
you
know,
Google
Voice
number,
for
example
like
there's
no
seem
to
swap
essentially
so
you
know
go
for
for
services
that
do
not
have
like
a
Sim
associated
associated
to
it.
Yeah.
Z
Z
For
this
conference-
and
this
is
like
this
is
why
we
talk
about
like
the
culture
right,
we
talk
about
the
organization,
we
talk
about
the
people
and
like
how
important
that
is
from
the
ground
up.
It's
like
every
little
decision
that
you
make
has
to
be
the
most
secure
one
right
and
so
that
you
have
all
the
different
layers
on
top
of
each
other,
so
that
it's
less
likely
that
things
happen
that
are
really
bad.
But
even
if
those
things
happen,
you
can
mitigate
the
loss,
you
can
respond
to
loss
quickly.
U
F
B
B
B
B
B
AD
AD
AD
AD
C
P
So
welcome
to
my
talk:
I'm
Raja,
franek
and
I
work
as
a
former,
very,
very
formal
verification,
engineer
for
one-time
verification
and
today
I
want
to
talk
to
you
about
surrounding
errors
and
what
we
can
do
about
them.
So
very
roughly
speaking
and
I'm
really
oversimplifying.
There
are
two
things
that
can
go
wrong
when
we
do
approximate
arithmetic,
in
contrast
to
exact
arithmetic
the
first
one
is
our
the
rounding
error
that
we
do
is
just
too
big
too
far
away
from
the
exact
result,
and
that
is
a
problem
in
itself.
P
But
that
is
not
the
topic
of
today.
So
I
want
to
talk
about
the
second
thing
that
can
go
wrong,
and
that
is
what
can
happen
is
that
you
want
to
approximate
a
value
From
Below
or
you
want
to
come
from
above,
but
you
do
it
in
the
wrong
direction
like
in
other
words,
you
want
to
round
down,
but
you
round
it
up
instead
and
that
can
lead
to
civil
security.
P
Vulnerabilities
I
will
show
you
some
examples
that
you
will
recognize,
maybe
and
then
but
I'm
not
going
to
work
on
these
real
world
examples.
I'm
working
on
a
like
simplified
example
and
make
sure
to
understand
like
the
two-way
trading
problem,
because
otherwise
you
won't
be
able
to
follow
my
talk.
Everything
like
get
to
this
point
stay
with
me
until
this
point,
and
then
you
can
make
sense
of
this
talk
so
grounding
errors.
P
P
It's
not
feasible
so
and
we
found
rounding
errors
in
uni
Swap
and
luckily
this
running
error
was
fixed
before
unisoft
V1
was
deployed,
but
I
leave
it
to
your
imagination
how
the
blockchain
landscape
would
have
looked
like
if
this
bug
was
not
caught
during
an
audit,
and
then
we
had
like
two
more
examples:
Solana
token
Landing
contract
and
Solana
talking
stable,
swap
and
there,
so
the
these
bugs
were
actually
caught
doing
like
why
these
contracts
haven't
deployed,
and
at
the
peak
time
there
were
like
three
billion
assets
at
risk.
P
So,
luckily
again,
these
were
not
exploited
by
the,
but
they
were
found
by
white
hackers
before
any
serious
damage
could
could
be
done
so
I
cannot
get
into
detail
into
any
of
those.
But
like
I
promise
you,
if
you
follow
my
talk,
then
you
will
be
able
to
visit
the
links
that
I
put
on
the
slide
and
you
will
be
able
to
make
sense
of
these
exploits
and
and
like
how
or
these
vulnerabilities
and
how
they
could
have
been
exploited
if
they
haven't
been
fixed.
P
So
I
want
to
show
you
the
two-way
trading
problem
and
I
promise
you.
This
is
like
the
most
mathematical
slide
on
my
on
my
entire
talk,
which
is
strange
well
because
I'm
talking
about
running
errors
right,
okay,
but
I
want
to
introduce
to
you
to
my
imaginary
friend,
Alice
she's
right
here.
Hi,
Alice
and
I
will
demonstrate
to
you
the
two-way
rounding
problem
as
the
two-way
trading
problem.
So
first
I'm
going
to
offer
Alice
a
trade
and
we
do
it
with
exact
arithmetic
and
then
we're
doing.
P
We
are
going
to
replay
the
wall,
the
role
play,
and
then
we
are
doing
it
with
rounding.
So
hi
Alice
also
basic
scenarios.
We
have
two
currencies,
we
have
dollar
and
Gill.
Gill
is
just
a
fantasy
currency
and
we
have
an
exchange
rate.
Currently
that
says,
I
can
get
like
to
kill
for
one
dollar.
So
exchange
rate
is
two
so
I'm.
Raul
I
have
one
Gill
in
my
pocket,
and
this
is
Alice
and
hey
Alice.
Do
you
want
to
trade
with
me?
P
I
can
offer
you
one
girl
how
many
dollars
do
I
get
for
that
and
Alice.
Do
the
calculation
he's
giving
me
one
dollar?
He
gives
me
one
girl,
so
I
need
to
divide
by
the
exchange
rate.
So
you
get
one.
You
get
half
a
dollar
back
from
me.
So
now,
I
have
half
a
dollar,
so
I
get
back
to
Alice
and
say:
hey
Alice
I
don't
want
my
half
dollar
anymore.
P
Can
I
get
my
deal
back
and
I
offer
Alice
the
half
the
dollar
and
she'd
use
a
computation
and
now
this
time
she
needs
to
to
to
multiply
by
the
exchange
rate,
and
so
she
ends
up
with
one
girl.
Everything
went
fine,
I
started
with
one
Gill
and
I
ended
up
with
one
kill
right.
So
now,
let's
do
the
same
thing
with
rounding
so
and
for
Simplicity
I'm,
just
rounding
to
like
there's
there's
no
decimal,
no
digit
after
the
decimal
point.
That's
just
for
Simplicity!
P
So
now,
Alice
I'm
Raul
I
have
one
Guild
to
offer
how
many
dollars
do
I
get
for
that?
Let's
use
the
computation,
and
but
she
does
a
rounding
error.
Do
I
have
a
laser
pointer
here?
No
I
don't
so.
She
does
a
rounding
error
in
this
computation.
So
we
divide
two
by
one.
This
gives
us
two
and
then
we
want
divide
one
by
two
which
gives
us
0.5
and
we
are
using
rounding
to
the
nearest
neighbor
here.
So
that
means
we
are
rounding
up.
P
So
that
means
I
get
one
dollar
back
from
Alice.
So
now,
I
have
one
dollar
I
go
back
to
Alice
and
say:
hey
Alice
I
don't
want
my
dollar
anymore.
Can
I
get
my
Gill
back
and
again,
let's
do
the
calculation
this
time
she's
not
even
doing
a
rounding
error,
but
she
ends
up
giving
me
two
kill
and
that
is
the
basic
problem
right.
P
P
So
the
important
thing
here
in
this
example
was
that
I
needed
two
trades
and
like
in
in
many
smart
contracts.
You
will
see
a
pair
of
trading
functions
like
a
deposit
and
a
redu-im
function
or
deposit
and
withdraw
stake
and
an
unstake
function
and
so
on,
and
so
what
what
happened
here?
What
went
wrong
like
now
have
a
look
at
the
red
line,
so
I
deposited
one
Guild
to
Alice
and
then
I
immediately
redeemed
it
like
in
the
same
transaction
and
I
was
able
to
make
two
Gill
out
of
that.
P
So
I
created
money
out
of
thin
air.
So
now,
okay,
so
we
we
don't
want
that
right.
We
need
to
fix
that,
so
we
need
to
like
make
a
sanity
check,
that
we
don't
get
like
more
money
out
than
we
put
in,
and
this
is
the
second
line
here.
P
This
is
my
sanity
assumption
that,
when
I
put
one
Guild
into
the
contract
or
I
should
be
able
to
get
at
most
one
kill
out
if
I
immediately
redeem
and,
of
course,
this
concept
can
be
generalized,
it
shouldn't
only
hold
for
one
gear,
but
it
should
essentially
hold
for
for
arbitrary
amounts
that
I'm
putting
into
the
contract.
P
So
this
is
what
a
typical
the
typical
implementation
of
a
deposit
and
a
redeem
function.
Look
like
looks
like,
and
what
you
can
see
here
is
like:
let's
walk
over
the
deposit
function,
real
quick,
so
the
deposit
function
accepts
an
asset
amount
and
then
it
converts
this
asset
amount
into
shares.
Just
by
multiplying
the
amount
of
assets
with
the
current
exchange
rate,
then
we
are
transferring
the
asset
we
are
pulling
in.
P
We
are
pulling
the
Assets
in
from
the
from
the
user,
then
we
are
minting
some
shares
and
finally,
we
return
the
shares
that
we
have
minted
and
the
redeem
function
is
similar
and
with
what
I
just
told
you
you
can
see-
or
maybe
you
cannot
see
it
because
well
I
didn't
use
the
you
cannot
see
the
implementation
of
the
multiplication
function
but,
like
this
contract
is
suffering
from
the
exact
vulnerable
ability
that
that
I
showed
you
before,
and
that
was
present
in
a
like
more
complicated,
a
more
complex
setting
in
this
in
this
unit
swap
contract
that
I
talked
about
earlier.
P
So
this
multiplication
function
and
this
division
function
is
is
implemented
as
like
rounding
to
the
nearest
neighbor,
and
that
is
the
mistake
that
we
did
here
but
like
how
do
we
actually
know
in
which
direction
we
should
round
and
there's
like
a
very
simple,
a
very
simple
rule
of
some
rule
of
thumb
that
I
can
give
you
and
that
is
I
call
it
keep
the
change
that
means
whenever
we
whenever
we
are
rounding
up.
P
Oh
sorry,
whenever
we
have
incoming
assets
like
accept
assets
from
the
user,
then
we
are
going
to
round
up
and
whenever,
like
we
are
sending
assets
out
to
the
user,
we
are
rounding
down,
and
if
we
follow
this,
this
rule,
that
means
you
will
approximate
your
values
from
the
right
direction,
and
users
won't
be
able
to
create
money
out
of
thin
air
and
doing
your
contracts.
That
is
the
simple
rule.
P
So
that
means
like
let's
revisit
the
example
from
before
so
like:
let's
walk
over
the
deposit
function
so,
instead
of
like
just
multiplying
I,
just
know
now,
I
use
now
a
variation
of
the
multiplication
function
that
always
rounds
down
and
it
runs
down
because
I'm
sending
the
assets
out
to
the
user
and
for
the
redeem
function
here
in
this
example.
It's
it's
the
same.
P
How
can
we
actually
be
sure
that
our
implementation
is
correct?
I
mean
this
example
was
really
simple
and
you
were
maybe
able
to
follow
it
like
on
the
spot,
but
but
like
when
you're
working
when
you're
a
developer
and
working
on
a
like
real
world
contract.
Your
logic
will
be
more
complex,
so
you
want
to
have
tests
that
ensure
that
you
can
actually
detect
counter
examples
and
achieve
a
higher
level
of
confidence.
P
So
we
are
now
looking
at
a
at
a
property
test,
so
that
is
basically
just
like
a
unit
test,
but
it
has
parameters
parameters
to
it.
So
it
has
two
parameters:
shares
per
asset,
which
should
just
it's
just
the
current
exchange
rate
and
it
has
another
very
another
parameter
assets
and
when
this
test
is
run
Foundry
by
the
way,
that's
a
Foundry
test.
P
I,
don't
know
if
I
have
said
that
I
so
and
when
Foundry
wants
this
test,
it
will
like
insert
call
this
test
with
a
bunch
of
random
inputs
like
and
that's
the
benefit
of
a
unit
test.
When
you
have
a
unit
test,
and
you
want
to
detect
such
routing
error,
you
basically
need
to
be
lucky
and
like
put
the
right
numbers
into
the
unit
test
and
guess.
The
counter
example
like
with
this
Foundry
test.
P
Foundry
does
a
guessing
for
you,
and
can
it
do
much
quicker
than
you
ever
could
like
it
can
one
like
1000
samples
or
two
thousand
two
thousand
samples
in
a
couple
of
milliseconds
so
and
I
want
now
to
have
you
a
look
at
line
14
and
15
and
see
that
it
resembles
the
property
that
we
specified
above
so
I
hope
that
you
can
see
in
line
14,
that
we
are
like
executing
a
deposit
function
and
in
the
same
transaction
we
are
executing
the
redeem
function
and
like
that
is
exactly
what
the
property
is
above.
P
P
These
are
just
some
assumptions
that
I
make
over
the
inputs
and
I
put
these
assumptions
there
just
to
avoid
arithmetic,
overflow
and
arithmetic
underflow,
because
if
I
went
into
such
a
situation,
my
test
would
simply
revert
and
I
I
only
want
to
execute
like
the
happy
path
and
with
this
test
and
then
like
line
eight
to
line
12
is
just
a
basic
test
setup,
so
that
I
that
my
contract
is
in
a
state
that
it
can
actually
fulfill
the
transfer
functions
that
I'm
calling
in
line
14..
P
So
fuzzing
is
good
and
you
should
actually
you
should
do
it
when
you
test
for
rounding
errors,
but
like
fuzzing,
is
not
enough.
That's
the
the
the
sad
message
here
like
the
third
example
from
the
from
the
first
slide
that
I
showed
you
this
example.
It
was
the
Stables
stable,
swap
contract
suffered
from
this
rounding
Direction
vinyl
ability,
although
it
was
heavily
fast
and
like
this
excerpt
that
you
see
here,
is
like
from
the
blog
post.
P
That
explains
this
vinyl
ability,
and
just
let
it
read
me,
let
it
let
me
read
it
out
to
you
so
another
interesting
takeaway
is
that
fuzzing
can
give
you
a
false
sense
of
security.
Prior
to
our
report,
saber
had
already
deployed
comprehensive
fuzzles
for
their
stay
for
their
swept
implementation.
A
researcher
looking
at
the
code
coverage
alone
might
come
to
the
incorrect
conclusion
that
such
extensively
fast
code
couldn't
possibly
have
a
vulnerability
all
right.
P
So
what
else
can
we
do
to
increase
our
confidence
in
in
our
implementation
and
like
one
possible
solution,
is
that
we
could
use
like
that?
We
could
use
symbolic
execution
on
top
of
fuzzing.
So
if
you
see
that
table
on
the
left
hand
side,
there
are
some
like
some
properties
that
that
fuzzing
has
and
on
the
right
hand,
side
on
the
white
column.
P
If
you
combine
both
of
these
efforts-
and
we
recently
so
we
at
one
time
verification-
we
have
a
symbolic
execution
engine-
that's
called
KVM,
that's
it's
a
symbolic
execution
engine
tailored
to
the
to
to
the
ethereum
virtual
machine,
and
we
recently
added
a
feature
to
that
that
allows
you
to
put
Foundry
tests
into
it
and
instead
of
fuzzing
over
the
parameters.
So
instead
of
choosing
random
input
variables
for
the
parameters,
and
we
do
symbolic
execution
over
the
over
the
parameters
and
that
has
like
different
trade-offs.
P
So
the
nice
thing
is
that
well
for
Foundry
and
for
symbolic
execution
with
the
evm,
you
get
to
specify
your
tests
and
your
specifications
in
Foundry
itself
in
solidity
itself.
Sorry,
so
that's
that's
like
easier
than
than
having
to
to
to
write
your
tests
in
JavaScript
or
typescript
developers
like
Foundry,
especially
because
of
this
property.
P
So
but
that
also
means
like
when
it
comes
to
Foundry
that
you
are
somewhat
limited
to
the
expressiveness
of
solidity
and
there
are
a
bunch
of
like
safety
properties
that
you
simply
cannot
express
in
solidity,
and
that's
like
one
advantage
of
this
symbolic
execution
approach
like
that.
You
can
actually,
you
can
escape
from
from
the
from
the
specification
format,
and
you
can
actually
use
the
the
K
language
to
specify
to
gain
additional
expressiveness
and
express
more
properties.
P
So
Foundry
fuzzing
is
extremely
fast.
It's
like
you,
can
one
1000
samples
in
a
couple
of
milliseconds,
and
that
is
like
really
important
for
for
developers
who
want
to
get
instant
feedback
so
and
compared
to
that
symbolic
execution
is
slow,
so
and
there's
a
reason
for
that.
So
symbolic
execution
can
give
you
much
more
safety
guarantees
than
than
fuzzing
can.
But
that
also
means
like
it's.
P
It's
computationally
much
more
expensive
than
fuzzing,
so
it's
slow,
but
it's
not
too
slow
like
it
works.
For
example,
you
could
simply
integrate
it
into
your
CI
Pipeline
and
let
the
let
the
prover
run
like
on
your
nightly
builds
for
example
and
like
this
shows,
like
the
benefit
of
like
composing.
Both
strategies
like
fuzzing
with
Foundry
and
then
symbolic
execution
with
with
KVM.
P
I,
don't
want
to
go
over
every
line
in
this
table,
and
but
I
want
to
talk
about
the
the
false
positives
and
the
false
negatives,
so
Foundry
doesn't
have
false
positives
and
what
I
mean
by
that
is
when
Foundry
comes
up
with
a
counter
example,
that
means
that
counter
example
really
works.
It
breaks
your
code,
so
it
doesn't
come
up
with
a
with
a
counter
example
that
does
not
work
your
code,
so
there's
no
false
positive,
but
Foundry
has
false
negatives,
and
that
is
simply
if
Foundry
is
not
able
to
choose
the
right
input
variables.
P
That
means
it
fails
to
guess
the
right
counter
example
and
at
the
end
founder
will
tell
you
that
test
that
test
actually
passed,
and
that
is
like
the
false
sense
of
security
that
you
get
from
using
Foundry
alone.
So,
if
we
use
symbolic
execution
like
we
cover
100
of
the
input
domain,
and
we
will
find
that
counter
example
there's
no
matter
what
so
there
are
no
false
negatives.
When
you
use
when
you
use
kevm,
then
there's
a
diff
there's
another
trade-off,
and
that
is
Foundry
is
extremely
easy
to
use.
P
I
I'd
argue
it's
even
easier
to
use
than
than
hardhead
or
or
truffle
for
testing,
because
well
the
developers,
the
smart
contract
developers
are
already
familiar
with
with
solidity
like
the
language
that
they
use
to
write
their
contracts,
and
so
that
makes
foundu
very
easy
to
use
symbolic
execution
with
KVM
is,
is
a
little
bit
different
like
it's
very
easy
to
try
out
it's
it's
like.
P
If
you
have
it
installed
on
your
machine
and
you
have
Foundry
tests
specified,
you
can
just
try
running
the
KVM
on
that
and
maybe
you're
lucky,
and
maybe
the
KVM
will
tell
you
right
your
test
pass
or
your
your
your
yeah.
Your
test
was
proven
or
it
was
like,
or
we
found
a
counter
example,
but
in
some
cases
you
will
get
like
a
third
state.
That
is,
you
didn't
pass.
You
didn't
fail,
but
we
are
not
sure,
like
we
don't
know,
and
if
you
end
up
in
this,
we
don't
know
State.
P
That
is
when
a
human
needs
to
drive
the
proof
forward,
and
that
is
actually
something
that
needs
some
practice.
I
think
I,
don't
think
it's
impossible
to
learn.
I
learned
it
so
I'm
sure
you
guys
can,
but
it's
it's
harder
than
just
just
calling
a
Foundry
test.
So
one
final
example
of
running
running
Foundry
and
running
the
KVM
symbolic
execution
engine
on
the
same
test,
Suite
so
on
the
on
the
top
image.
P
I
just
called
Ford
test
and
I
can
see
the
output
like
that
tells
me.
Okay,
I
was
running
one
test
and
it
passed.
I
tried
256
samples
on
that
tested
that
it
means
Foundry
won.
This
test
was
256
different
inputs
and
then
I
can
use
like
after
I've
won
the
founder
test.
I
can
run
KVM
Foundry,
compile
and
give
it
a
Foundry
out
directory
as
a
parameter.
P
And
what
this
comment
will
do
is
it
will
turn
The
Foundry
test
Suite
into
a
proof
obligation
for
the
symbolic
execution
engine
like
it's
a
compile
step
and
then,
when
I've
done,
that
I
can
actually
try
to
discharge.
This
proof
obligation
by
wanting
KVM,
Foundry
proof
and
the
output
that
you
see
here
is
the
lucky
case
that
our
like
symbolic
execution,
was
actually
able
to
discharge
the
proof
of
obligation
and
that's
why
it
says
top
top
at
the
bottom.
P
So,
but
well,
when
this,
when
a
test
doesn't
pass,
you
will
get
a
counter
example
that
is
not
as
easy
like
to
link
back
to
the
original
code
of
the
test
than
the
then
The
Foundry
country
example,
or
even
worse.
It
will
give
you
this
unknown
State
and
like
making
sense
of
this
unknown.
State
really
requires
some
practice.
You
you
need
to
to
learn,
to
read
these
configurations
to
need
to
eat
these
stuck
States.
P
So
that's
basically
it
with
my
talk,
I've,
just
one
more,
a
couple
of
more
notes,
so
I
work
at
one
time,
verification
and
we
have
a
research
department
and
we
just
recently
posted
some
open
research
challenges
on
our
website.
Research,
dot,
runtime
verification.com,
and
if
you
are
a
researcher,
go
to
that
website,
see
if
something
interests
you
and
we
have
like
multiple
ways
to
collaborate
with
you
like.
P
If
everything,
if
anything
interests
you
all
right
and
then
like
one
other
announcement,
a
colleague
of
mine
Richards
in
the
audience
somewhere
I
see
them
he's
giving
a
workshop
on
formal
methods
for
the
working
defy
Dev
tomorrow
at
at
11AM
in
Workshop
room
number
three.
So
if
you
like
this
talk,
go
ahead
and
visit
Richard's
talk,
it's
I
highly
recommend
it
right
and
that's
it
I
think
we
have
some
time
for
questions.
Do
we
we
have
do
we
have
a
microphone
for
questions.
AE
Hello,
great
great
presentation,
I
have
a
couple
of
questions.
Can
you
go
back
to
the
table
that
you
show
both
like
fasting
and
symbolic
execution.
AE
Great,
so
you
you
put
like
in
the
fasting
column
that
it
requires
no,
inter
in
human
intervention,
but
you
need
someone
to
write
the
properties.
It's
the
same
for
the
symbolic
execution
right.
So
if
you
have
good
properties,
you
will
catch
good
bugs.
If
you
don't
have
good
properties,
you
will
have
catch
no
bugs
right,
and
this
is
the
same
with
the
examples
that
you
show
like
see.
Fasting
is
not
enough.
This
code
was
fast,
but
perhaps
they
are
not
using
the
correct
properties.
So
what
is
what
is
your
take
on
this
yeah.
P
Yeah,
that's
true,
so
this
is
not
like
fully
automatic
like,
for
example,
when
you
run
a
static
analysis
tool
on
your
code
base,
then
you
essentially
have
to
do
nothing.
You
can
just
like
hit
a
button
and
one
Slither
on
your
code
base.
So
for
fuzzing
you
need
to
write
down
the
tests
and
like
like
getting
the
tests.
Getting
the
white
tests
is
a
challenge
on
its
own.
P
It's
not
like
it
doesn't
come
easy,
it
has
to
be
practiced
and
the
same
is
even
more
to
when
you
do
symbolic
execution
because
well,
symbolic
execution
can
also
can
also
be
a
foot
gun
if
you
don't
know
how
to
use
it
appropriately.
All.
AE
Right,
yeah,
yeah,
definitely
and
the
other
thing
very
quickly.
You
you
put
like
false
negatives,
like
on
fun
on
fasting,
which
is
which
I
agree
and
you
put
no
false
negative
on
symbolic
execution
or
wherever
you
said
that
you
could
have
a
third
state
in
which
you
don't
know.
If
it's
true
or
is
false,
that
sounds
like
a
false
negative
to
me.
Like
you,
you
don't
know
the
answer.
The
tool
doesn't
know
the
answer,
so
it
is.
It
is
like
yeah.
P
But
it
doesn't
say:
I
discharged
this
proof
obligation
and
everything
is
right.
It
says
you
I'm
stuck,
and
that
is
you
should
interpret
this
as
I
need
to
put
more
effort
in
the
proof
or
in
the
code
to
get
it
to
like
a
final
state
that
says
true
or
false.
AE
P
Could
try
like
fuzzing
over
like
the
entire
input
space
and
then
you
will
also
have
like
no
Faults
of
no
false
negatives.
You
could
try
that
but
like
you
will
never
terminate
like,
but
but
that
would
work
yeah.
AF
C
B
B
C
All
right,
hello,
everyone
halfway
through
the
day,
our
next
talk
is
going
to
be
a
really
interesting
talk
by
two
chain:
analysis,
investigators
and
they're-
going
to
talk
about
the
10
billion
dollar
problem
web
3,
security
against
coordinated
adversaries.
So
please
welcome
Adam,
Hart
and
Julia
Hardy.
AA
Foreign
for
joining
this
talk,
I'm,
Julia,
Hardy
I'm,
here
with
Adam
Hart,
and
we're
here
from
genealysis
to
talk
to
you
about
the
10
billion
problem,
so
we're
looking
at
coordinated
adversaries
that
are
working
within
ethereum
and
the
web
3
space.
First,
you
might
be
wondering
who
is
chain
analysis.
Why
do
we
care
about
this
issue?
AA
We
also
provide
attribution-
and
we
put
all
that
together
into
our
different
products
that
we
have
and
the
one
that
we
use
as
investigators
mainly
is
reactor,
which
is
our
blockchain
visualization
tool,
and
so
what
we're
doing
in
our
day-to-day
is
we're
looking
at
what
have
been
different,
Arts
place
that
have
happened,
we're
mapping
out
that
activity
on
chain
and
when
we're
looking
back
at
the
past
year,
it
can
feel
like
there's,
been
an
exploit
every
week,
if
not
every
day.
AA
In
some
cases,
some
of
these
have
been
the
larger
Bridge
exploits
that
have
been
discussed
today,
there's
even
the
BNB
Chain
Bridge
just
last
week.
There
are
things
like
the
discords
and
the
twitters
that
have
been
compromised
and
they
end
up
having
fishing
links
posted
on
them.
There
are
things
like
the
Oracle
exports
that
come
out
and
what
we
do
is
we
Trace?
What
has
happened
with
those
funds
and
we
look
for
patterns
of
activity
and,
ultimately
we're
asking
the
question
to
ourselves.
AA
Do
we
think
that
these
are
all
separate
events
that
have
occurred
in
the
past
year
or
do
we
see
any
coordinated
attacks
happening?
Do
we
see
that
there
are
the
same
adversaries
that
are
working
and
having
multiple
exploits
in
the
space
and,
as
you
might
imagine,
from
our
title,
we
do
see
some
coordination
here.
AA
So
this
is
a
pretty
crazy
number,
pretty
large
part
of
the
defy
exploits
that
have
occurred,
and
when
we
look
at
what
kind
of
exploits
they
are
conducting,
we
see
that
they're
really
following
the
money.
So
originally
there
was
most
of
the
money
concentrated
in
Bitcoin
and
then,
as
ethereum
has
taken
off
as
there's
been
D5
summer
and
yield
farming
and
nft
trading.
We
see
that
dprk
has
shifted
and
they're
focusing
a
lot
more
on
stealing
ether
and
erc20
tokens.
AA
So
this
is
a
map
of
the
flow
of
funds
for
the
Ronin
Bridge
hack,
and
this
is
really
a
high
level
view.
But
you
can
imagine
if
you're
zooming
in
each
of
these
dots
here
is
a
separate
address
or
a
separate
group
of
addresses
and
the
lines
between
them
are
flow
funds.
So
you
can
see
just
how
well
coordinated
this
adverse
area.
AA
Is
they
are
able
to
move
funds
24
7
across
blockchains
through
mixers
and
just
are
very
well
resourced
and
well
understanding
of
how
to
launder
in
this
space,
but
we
can
also
use
those
patterns
that
we
see
from
Ronin
from
other
hacks
to
be
able
to
identify
how
dprk
works
so
from
there.
We
can
look
at
past
talks
that
have
happened
and
say
well.
Do
we
think
this
is
actually
dprk?
AA
Are
they
following
these
same
laundering
strategies,
but
we
just
didn't
know
before,
and
we
can
also
look
forward
and
if
a
future
x-plate
occurs,
we
can
take
a
look
and
say:
do
we
see
these
same
patterns
happening
there?
Do
we
think
that
this
is
another
DPR
activity
and
then
hopefully,
ultimately
help
to
prevent
the
flow
funds
to
cash
out
points.
AG
Great
and
so
Julia
just
walked
us
through
a
very
brief
overview
of
some
of
the
the
North
Korean
activity
and
there's
definitely
been
talks
in
this
room
earlier
today
about
exactly
how
some
of
those
you
know
those
attacks
are
actually
executed.
But
what
we
really
wanted
to
dive
into
in
this
session
are
some
of
the
coordinated
adversaries
that
maybe
receive
a
little
bit
less
media
attention,
but
are
equally,
if
not
more
damaging
to
the
ecosystem,
so
dprk
definitely
a
major
threat,
one
that
deserves
all
of
the
attention
that
it
gets.
AG
It's
just
that
on
chain.
We
we
certainly
see
other
activity
as
well,
so.
AG
And
Julia,
which
one
goes
forward
there
we
go
perfect.
So
you
know
a
common
problem
that
we
come
across
as
Julie
mentioned
earlier.
Is
the
you
know,
sheer
volume
of
hacks
exploits
other
other
event,
scams
that
occur,
and
the
question
that
that
we're
always
trying
to
ask
is:
are
these
different
entities
that
are
all
just
copying
each
other
or
is
this
one
coordinated
adversary?
Because
if
it's
a
coordinated
entity,
then
they're,
probably
more
sophisticated,
more
organized,
probably
doing
more
damage
and
the
the
attack
vectors
can
vary.
AG
So
it
can
be
something
like
compromised
web
2
infrastructure.
We,
we
just
had
a
really
great
talk
in
this
room
about
how
how
those
sorts
of
exploits
occur.
But
one
of
our
questions
is,
you
know:
is
this
the
same
entity?
That's
maybe
going
after
DNS
registrations
or
is
it
different
entities,
and
the
same
goes
for
any
sort
of
compromise
of,
say,
a
Discord
server
or
a
popular
Twitter
profile,
a
trusted
method
of
communication.
AG
That
again,
you
know
tricks
users
into
doing
something
that
they,
they
probably
shouldn't,
be
doing
on
the
blockchain
and
the
way
we
sort
of
approach.
This
problem
of
you
know
identifying
coordinated
entities
in
the
first
place
is
a
combination
of
traditional
cyber
security
analysis.
So,
looking
at
things
like
what
infrastructure
is
used
in
the
attack,
you
know
what
systems
are
compromised.
AG
What's
the
specific
attack
Vector,
but
then,
as
as
was
just
shown
in
the
case
of
looking
at
North
Korean
activity,
but
what
we
can
also
apply
to
sort
of
these
other
coordinated
actors
is
looking
at
what
occurs
on
the
blockchain.
So
this
is
where
the
the
transparency
of
you
know,
something
like
ethereum
is
really
really
useful
to
us.
AG
As
security
analysts
trying
to
sort
of
understand
these
Bad
actors,
because
we
can
look
at
things
like
how
is
the
victim
actually
losing
funds,
and
that
might
be
something
really
sophisticated
like
a
re-entrancy,
you
know
exploit
in
in
a
popular
smart
contract,
or
it
can
be
something
as
simple
as
fishing
for
token
approvals.
AG
You
know
the
the
simple
attacks
sometimes
are
the
most
damaging,
but
you
know
the
the
precise
sort
of
payload
can
be
very
illustrative
and
help
us
understand
these
groups
and
then
also
we
can
track
the
funds
after
the
attack
occurs
now.
Unfortunately,
this
is
reactive.
This
is,
after
victims
are
losing
money,
but
again
it
can
help
us
understand
our
our
adversaries,
the
the
Bad
actors
on
the
blockchain
better
and
start
to
map
out
the
the
true
sort
of
scale
of
the
challenge
that
we're
up
against
here.
AG
So
to
delve
into
that
a
little
bit,
we
actually
wanted
to
spend
a
little
time
here,
walking
through
a
case
study
of
how
how
we
approach
this
problem
and
also
hopefully
drive
home.
The
point
that
you
know
North
Korea,
is
definitely
not
the
only
coordinated
adversary
out
there.
So
the
particular
example
here
is
something
that
we
refer
to.
As
a
you
know:
tether
usdt
approval
mining
scam
so
to
the
folks
in
this
room,
those
words
might
not
really
make
sense
together
right.
You
know,
you
don't
mind
anything
with
tether.
AG
You
know
what's
going
on
here,
but
the
essentially
the
the
attack
here
is
not
targeting
folks
who
are
attending
Devcon.
This
is
a
targeting.
You
know
newer
crypto
users,
primarily
targeting
mobile
crypto
users,
folks,
who
are
maybe
getting
into
the
ecosystem
for
the
first
time,
the
next
billion
users,
but
instead
of
you
know
engaging
with
a
a
normal.
You
know
dap
or
you
know
something
interesting.
Instead,
the
users
are
maybe
social
engineered
into
going
to
a
website.
AG
Maybe
they
have
some
tether
in
their
wallet
and
they
hear
from
a
trusted
friend
that
they
met
on
the
internet,
that
there's
this
really
great
opportunity
to
make
some
money
and
they
don't
even
have
to
send
their
tether
anywhere,
because
you
know
they,
you
know
red
flags
go
up.
If
you
send
your
token
somewhere,
but
they
just
go
onto
this
site.
AG
They,
you
know,
buy
a
little
voucher
to
participate
in
this
node
mining
and
from
there
they
can
start
earning
some
pretty
great
rewards,
and
everyone
knows
you
know
you
can
make
some
money
off
off
of
crypto.
That's
that's
always
nice,
however,
as
was
very
well
reported
by
the
metamask
security
team,
it
turns
out
that
naturally,
this
was
not
the
the
true
application.
What
was
really
happening
here
is
when
the
users
were
going
on
to
this
website.
What
they
were
seeing
was.
AG
You
know
some
screen
that
said:
hey,
you're,
earning
great
rewards,
all
you
have
to
do
is
buy
a
little
voucher
to
claim
those
rewards,
but
when
they
bought
that
voucher,
what
they
really
did
was
approve
another
address
to
move
the
tether
sitting
in
their
wallet
and
again
this
is
a
really
common
attack.
Factor,
certainly
not
a
new
one.
It's
been
around
forever,
but
it
still
tricks
a
lot
of
users.
AG
Users
don't
understand
what
this
approval
is,
that
they're
signing
and
naturally,
once
the
bad
actor
gets
the
user
the
victim
to
approve
their
address,
to
move
their
funds.
They
can
now
clean
out
all
the
tether.
That's
sitting
in
that
address
and
what
we
can
see
thanks
to
the
great
work
of
metamask,
is
metamask
as
a
very
popular
wallet
provider,
they've
received
lots
of
tickets
from
users
who
had
been
scammed
and
they
noticed
a
trend
on
the
off-change
side.
They
noticed
a
a
similarity
in
how
these
users
were
being
tricked.
AG
They
noticed
similarities
in
some,
some
of
the
domains
being
used
to
to
you
know,
trick
these
users
and
from
that
they
published
a
awesome,
Dune
dashboard
showing
60
addresses
that
were
scamming
users,
I.E
60
addresses
that
were
being
granted
approvals
from
victims
and
those
60
addresses
had
managed
to
scam
somewhere
in
the
range
of
83
million
dollars
over
the
course
of
a
year.
Now,
that's
that's
already
in
the
range
of
some
of
the
major
Bridge
hacks.
AG
However,
we
can
go
beyond
this
right
because
metamask
as
a
wallet
provider
they're
the
first
point
of
contacts,
they're
they're,
getting
the
reports
from
users,
but
what
we
do
as
a
blockchain
analytics
company
is
we
try
and
build
out
patterns,
so
here
with
60
addresses,
we
can
look
in
a
variety
of
directions,
so
the
reported
scam
addresses
are
shown
here
and
one
of
the
first
things
that
we
might
do
in
investigation
is
say:
okay,
how
were
these
different
addresses
funded?
AG
How
did
they
get
the
ether
that
they
needed
to
execute
transactions
on
the
blockchain
again?
This
is
one
of
many
avenues
that
we
pursue,
but
you
know
from
there
we
might
might
be
able
to
identify
related
addresses
and
from
there
maybe
we
can
start
identifying
some
patterns.
AG
Maybe
we
notice
there
are
some
addresses
that
appear
to
be
testing
these
phishing
scripts
right,
they're,
they're,
testing,
the
approval
function,
they're
funded
from
the
same
entities
clearly
related
to
what's
going
on
here
and
with
that
pattern,
recognition
by
looking,
you
know
at
the
funding
by
looking
at
these.
These
you
know
testing
patterns
and
others.
AG
We
can
start
to
identify
additional
addresses
that
are
receiving
approvals
from
victims
that
are
following
this
exact
same
pattern
of
getting
that
approval
from
the
victim
and
then
transferring
the
tether
out,
everything
looks
alike,
and
so
now
you
know
we're
starting
to
expand
our
our
understanding
of
the
adversary.
Here,
where
things
really
get
interesting,
though,
is
when
adversaries
are,
are
coordinated
and
organized,
as
is
the
case
here.
This
is
a
persistent
scam
that
that's,
you
know
lasted
over
a
year.
There
is
some
point
of
con.
AG
You
know
consolidation,
some
pattern
we
can
identify
and
we
identified
a
consolidation
Point
here
funds
were
being
gathered
in
a
very
specific
Manner
and
from
that
consolidation
point
we
can
really
start
to
understand
the
true
scale
of
this
scam,
and
it
turns
out
that
when
we
really
mapped
out
this
scam-
and
certainly
the
mapping
is
not
complete
here-
we
were
able
to
go
from
the
60
addresses
that
metamask
reported
from
from
their
victims
to
91
additional
addresses
that
we
identified
doing
the
exact
same
thing,
where
we
are
very
confident
that
they're
all
controlled
by
the
same
entity.
AG
So
these
91
addresses
plus
the
original
60
addresses
they
take
victim
funds
and
they
spread
them
out
to
all
sorts
of
addresses.
They
spread
them
out
to
879
other
addresses
so
already
we're
again
seeing
a
very
clear
laundering
pattern
as
Julia
we'll
get
into
in
just
a
moment.
But
you
know
we
we
can
start
to
map
out
where
those
funds
go
and
additionally,
we
can
identify
how
many
victims
are
actually
being
hurt
by
this
scam,
so
metamask
in
their
original
Doom
dashboard,
which
again
you
know
they
they
did
a
fantastic
job
publicizing.
AG
This
and
you
know
we
wouldn't
be
able
to
get
started
without
their
work,
but
here
we
were
able
to
identify
more
than
11
000
additional
victims,
and
this
is
where
these
sorts
of
persistent
scams,
although
less
technically
sophisticated
than
something
like
an
exploit,
really
damaged
the
community,
because
now
we've
got
over
20
000
likely
victims,
and
these
likely
victims
are
probably
first-time
users
and
they're
going
to
go.
Tell
all
their
friends
that
you
know
their
only
experience
in
crypto
is
getting
scammed.
AG
So
you
know
this
is
a
real
problem,
and
certainly
you
know
the
scale
is
pretty
shocking
as
well,
but
to
truly
understand
the
scale
of
of
these
sorts
of
scams.
We
also
not
only
have
to
map
out
the
infrastructure
being
used
to
scam
victims,
but
also
where
the
funds
go
after
the
attack
and
for
that
I'll
pass
it
back
over
to
Julia.
AA
AA
AA
Then
we
see
the
funds
move
to
New,
addresses
and
preparation
to
start
to
interact
with
exchanges,
and
once
we
get
to
the
exchanges
at
the
bottom,
the
numbers
are
pretty
staggering.
We
see
10
million
going
to
a
single
deposit
address
at
an
exchange
on
one
line
there
31
million
add
another,
and
when
we
tally
up
all
of
those
different
values
that
we
see
from
this
flow
of
funds,
we
end
up
finding
143
million
dollars
worth
of
additional
stolen
value.
So
in
combination
with
what
matamask
initially
provided,
we
have
a
227
million
dollar
scam.
AA
Now
this
is
the
known
value.
When
we
look
at
that
entire
network
and
look
at
what
funds
are
actually
going
to
exchanges,
we
see
1.2
billion
dollars,
so
we
can't
know
without
further
investigation
that
all
of
those
funds
are
coming
from
this
one
tether
scam,
but
it
shows
what
the
upper
bounds
of
this
scam
value
could
really
be.
AA
The
other
thing
is
that
we
do
see
that
on-chain
coordination,
we
see
that
the
same
recipient
addresses
are
being
used
across
different
transfer
from
scammer
addresses.
So
we
can.
We
see
the
consolidation
points,
we
know
that
there
is
definitely
some
coordinated
activity
here
and
that
there
is
one
actor
behind
at
least
the
majority
of
this
exploit,
and
we
can
take
this
a
step
further.
AA
So
this
is
just
one
example
of
us
working
with
metamask
to
find
the
scam
and
find
its
full
levels.
But
really
we
want
this
to
be
a
starting
point
and
we
really
want
all
of
us,
as
a
community,
within
the
security
space,
to
try
to
work
a
lot
more
closely
together
and
we
can
raise
the
cost
for
Bad
actors
by
trying
to
use
some
of
these
different
points.
This
is
something
that
is
not
just
unique
to
us.
AA
We
know
that
those
that
are
working
in
the
ransomware
space
have
done
a
good
job
with
trying
to
work
a
lot
more
collaboratively,
and
we
think
we
can
do
a
lot
of
the
same
things
here
so
trying
to
have
more
data
sharing
between
the
victims
and
the
incident
response.
Firms
trying
to
use
blockchain
analytics
more
and
focus
on
that
combination
of
off-chain
and
on
chain
together,
trying
to
have
more
public
private
collaboration
and
trying
to
identify
Trends
and
share
that
research
with
each
other.
AA
AA
So
with
that,
we
thank
you
very
much.
We
would
really
like
to
talk
with
each
and
every
one
of
you
after
this.
If
you
have
any
ideas
about
how
we
can
collaborate
or
where
we
should
take
this
from
this
point
here
definitely
feel
free
to
follow
us
and
reach
out
to
us.
I
think
we
have
a
couple
minutes.
If
anyone
has
any
questions
offhand.
AG
F
AG
So
the
question
was
in
the
traditional
cyber
security
space.
We
we
talk
about.
You
know
apt's
advanced
persistent
threats,
whereas
we
use
the
term
coordinated
adversaries.
AG
We
didn't
want
to
confuse
the
the
cyber
security
side
of
things,
because
maybe
some
of
these
coordinated
adversaries
aren't,
you
know,
really
an
advanced
super
tech,
sophisticated
threat,
but
mostly
it's
just
terminology.
Choice
yeah.
R
So
in
the
case
study
we
saw
here
we
we
were
presented,
something
that
was
not
supposedly
looking
like.
It
came
from
the
Lazarus
group
or
the
dprk,
but
why
why
does
this
not
look
like
it
comes
from
from
the
deeper
care
the
Lazarus
group.
AA
I
mean
exactly
for
the
reasons
that
we
were
talking
about
so
using
that
off
chain
and
on-chain
pattern
and
from
what
we
have
historically
known,
how
Lazarus
tends
to
provide
spear
phishing
or
use
certain
methods
off-chain
how
they
tend
to
launder
on
chain.
It
just
isn't
following
that
pattern:
yep.
Q
Thank
you
for
the
talk
today.
Briefly,
you
mentioned
that
you
used
checking
how
wallets
were
funded
as
a
means
to
investigate
what
were
the
other
tactics
that
I
heard.
You
say
we
use
other
tactics.
What
are
the
other
tactics
that
you
use?
Yeah.
AG
I'll,
take
that
one,
so
my
my
day,
job
is
actually
to
to
run
training
courses
on
that.
Unfortunately,
it's
going
to
take
like
eight
hours
to
to
really
get
to
delve
into
that
one,
but
you
know
there
there's
a
lot
of
different
directions
to
look
in
generally.
We
we
look
both
forward
and
backwards
to
see.
AG
AG
So
so
the
question
was
with
respect
to,
to
you
know:
ZK,
Roll-Ups
and
and
other
DK
chains.
You
know
how
does
that
potentially
interfere
with
blockchain
analytics
it?
It
definitely
depends
I'll,
give
you
the
the
non-answer
there.
Different
chains
come
with
with
different
considerations
there,
but
you
know,
as
as
our
co-founder
stated,
you
know,
these
groups,
especially
Lazarus,
are
moving
something
like
600
million
dollars
in
a
shot,
like
that's
that's
kind
of
tougher
to
hide.
So
if
you're
operating
on
that
volume,
it's
it's
hard
to
hide
that
amount.
AA
Well,
thank
you.
Everyone
definitely
feel
free
to
find
us
later.
B
B
B
B
B
B
AD
AD
Cool
well,
thank
you
guys
all
for
coming.
My
name
is
Lane
Haber
I'm,
one
of
the
co-founders
at
connects,
where
I
focus
mostly
on
the
core
bridging
protocol
and
I'm
gonna.
Give
you
guys
a
talk
about
cross-chain
security
considerations
for
the
Degen
and
all
of
us,
and
hopefully,
by
the
end
of
this
talk,
you
guys
will
be
able
to
come
away
with
some
key
questions
to
ask
yourself
about
Bridge
security.
AD
So,
first,
why
is
Bridge
security?
Important?
Well,
Bridge
security
is
more
important
than
most
systems
because
you
can
be
subject
to
the
risk
of
the
bridge
when
you
never
even
touch
that,
and
what
do
I
mean
by
that?
Well,
polygon,
the
polygon,
POS
Bridge,
the
roll-up
ambs.
You
will
those
bridges
basically
work
by
locking
up
assets
on
one
side
and
delivering
you
a
minted
version
of
those
assets
that
represent
a
claim
on
the
locked
funds
when
everything
is
backed
one
to
one.
AD
This
is
works
great
because
you
can
trade
the
assets
on
your
destination
domain
freely
and
then,
whenever
anybody
wants
to
come
back,
they
can
easily
just
unlock
it.
Unfortunately,
if
your
bridge
is
attacked,
then
what
you
effectively
have
are
claims
on
something
that
don't
exist
anymore
and
you
are
subject
to
this
contagion
risk
whenever
you
are
using
those
assets.
AD
So
if
you're
on
polygon
and
you've
withdr
like
purchased
POS
usdc
with
your
credit
card
or
you've
exited
to
polygon
from
an
exchange,
you
have
never
used
the
bridge
and
you
were
still
subject
to
this
contagion
risk
that
exists
with
the
polygon
bridge
and
the
same
thing
applies
to
Roll-Ups
as
well:
well,
really
any
default
Bridge.
So
this
is
kind
of
just
a
visualization
of
the
risk
that
we
as
an
industry,
are
exposed
to
in
just
a
small
subset
of
default.
Bridges
this
these
numbers
may
have
changed.
AD
You
can
see
that
they
are
in
dollars,
but
it's
over
it's
close
to
four
or
five
billion
dollars,
that
of
assets
that
are
subject
to
this
type
of
risk.
But
that's
not
those
aren't.
The
only
bridges
that
are
getting
hacked
are
the
default
Bridges.
You
can
see
here
that,
like
Bridges,
just
keep
getting
hacked
and
in
just
under
14
months,
we've
lost
like
two
and
a
half
billion
dollars
and
I'm
sure
that
I
will
have
to
update
this
slide
soon
in
the
future
and
really
like.
AD
Why
are
bridges
so
easy
or
like
such
an
appealing,
Target
they're,
appealing
targets,
because
it's
new
technology,
like
I,
think
about
this
stuff
every
day
and
even
for
me,
the
way
that
we
are
thinking
about
security
or
thinking
about
the
best
way
to
bridge
between
chains
changes
all
the
time.
On
top
of
that,
it's
also
a
honey
pot.
So
because
you
lock
funds
up,
you
are
become
a
really
attractive
Target
to
hackers,
and
it's
not
just
like
the
custody
assets
to
create
the
minted
assets
are
the
only
ones
that
could
be
locked
on
the
bridge.
AD
If
you
have
a
high
latency
Bridge,
you
could
also
have
assets
to
like
that
kind
of
represent
more
of
a
liquidity
network.
If
you're
not
the
default
bridge,
then
you're
probably
going
to
want
some
type
of
amm
to
switch
into
the
asset
that
everybody
really
wants,
and
that
is
that's
just
all
a
lot
of
money.
That
is
an
appealing
Target
and
the
other
reason
why
these
Bridge
hacks
keep
happening
is
because
Bridge
technology
is
pretty
complex,
like
you
are
building
a
system
that
is
connecting
a
lot
of
heterogeneous
domains.
AD
So
not
only
do
you
have
to
know
everything
about
your
system,
but
you
have
to
know
everything
about
the
underlying
domains
that
you're
connecting
because
the
code
that
you
write
will
not
run
the
same
on
optimism
or
arbitrim
or
polygon.
There
are
slight
differences
that
will
impact
you,
because
those
slight
differences
that
you
may
not
understand
fully
are
going
to
be
the
ones
that
end
up
being
your
downfall.
AD
So
now
we're
going
to
talk
about
like
the
different
types
of
bridges
that
exist,
and
some
of
like
just
to
give
you
guys
a
easier
mint
model
to
evaluate
all
the
bridges.
So,
first
before
we
get
into
that,
you
can't
have
all
the
nice
things
you're
going
to
have
to
choose
some
and
there's
always
trade-offs
like
in
any
other
type
of
engineering
generally.
It
means
that
you
can't
have
all
four
of
these
properties.
It's
low,
latency,
meaning
the
transfers
or
message
passing
happens
quickly.
AD
It's
generalizable
meaning
you
can
pass
whatever
messages
you'd
like
through
the
bridge.
It's
trust
minimized,
meaning
that
you're
not
adding
any
additional
trust
assumptions
or
it's
extensible,
meaning
you
can
take
the
same
implementation
and
use
it
on
many
different
domains.
You
can
also
have
there's
missing
triangle,
but
you
can
also
have
low
latency
trust,
minimized
and
extensible
bridges.
Those
are
more
like
liquidity
networks
like
Atomic
transfers
would
have
that
because
you
can't
pass
General
data
through.
AD
You
can
only
pass
fungible
tokens
cool
so
what
types
of
bridges
exist
and
where
do
they
exist
on
this
trade-off?
Space,
there's
natively,
verified,
Bridges
and
natively
verified
ridges
are
bridges
where
the
domains
underlying
validators
are
the
ones
that
are
verifying
these
transactions.
This
is
something
like
like
client,
Bridges,
ZK
Bridges,
the
which
are
coming
out
now
or
like
even
the
roll-up
ambs
are
a
special
special
case
of
this
type
of
bridge.
AD
They
are
very
low
latency.
You
can
pass
whatever
information
you
want
through
them
and
they
are
trust
minimized.
However,
they
are
not
extensible
and
they're,
not
extensible,
because
generally
these
Bridges
depend
really
heavily
on
the
underlying
consensus
of
the
domains
that
they're
connecting
so
I
would
need.
A
completely
different
I
would
need
two
different
Bridges
if
I
were
creating
a
project
that
would
use
like
client
Bridges
everywhere.
AD
I
would
need
two
different
implementations
on
ethereum
if
I
wanted
to
connect
from
ethereum
to
Cosmos
or
ethereum
to
Solana,
there's
also
externally
verified
Bridges,
externally
verified
Bridges
have
a
third
party
validator
set
that's
verifying
these
Bridge
transactions.
AD
This
cut
is
low,
latency,
generalizable
and
extensible,
but
now
you
do
have
to
consider
what
happens
with
that
third-party
validator
set
the
implications
of
like
whether
or
not
the
bridge
validator
set
is
going
to
be
the
lowest
trust.
Point
in
your
system
really
depends
on
like
the
validators
of
the
domains
that
you're
connecting.
AD
So,
if
you're
connecting
flip-flop
chain
through
a
very
popular
bridge
to
ethereum
your
weakest
verifier
set,
is
probably
going
to
be
on
flip-flop
chain,
okay,
cool
and
then
there's
optimistically
verified
systems
optimistically
verified
systems,
use
fault
proofs
to
enforce
the
validity
and
veracity
of
the
messages
that
they're
passing
through
one
Quirk
about
how
you
have
to
construct
the
fault
proofs
for
these
types
of
systems
is
you
can
only
prove
that
fraud
happened
on
the
home
domain,
which
is
where
the
message
was
sent
from
generally.
AD
That's
because
all
of
most
optimistic
systems
have
some
type
of
Merkle
root
that
they
are
verifying,
and
you
can
only
prove
that
your
claim
of
fraud
was
valid.
If
you
know
the
contents
that
went
into
that
Merkle
tree.
However,
on
the
destination
domains
you
can
disconnect
the
the
chain,
so
they
don't
process
any
fraudulent
messages.
These
systems
are
trust,
minimized,
generalizable
and
extensible,
but
obviously
they
have
there
have
some
latency,
because
you
have
to
run
a
fault
proof.
AD
So
I
also
want
to
talk
briefly
about
ZK
Bridges,
just
because
they
are
coming
out
soon,
but
they're
not
available.
Yet
ZK
bridges
are
a
type
of
native
bridge
that
you
know
uses
a
validity
proof
to
ensure
consensus.
One
thing
that
you
have
to
consider
with
any
native
bridge,
where
it's
just
or
any
proof
where
it's
just
asserting
consensus
is:
if
there's
a
51
attack
on
one
of
the
domains,
that
malicious
information
would
be
treated
as
valid
when
it's
crossing
a
bridge
that
verifies
only
consensus.
AD
There's
some
really
interesting
work
to
validate
both
consensus
and
state
transitions,
but
it's
in
early
days.
Ultimately,
that's
probably
going
to
be
the
gold
standard
of
bridges,
but
it's
not
ready
for
prime
time
yet
so
now
we're
going
to
talk
about
different
types
of
security
and
where
these
Bridges
fare
in
those
trade-offs.
So
when
we
talk
about
security
of
these
cross
domain
systems,
we're
really
talking
about
three
different
types
of
security:
Economic
Security,
which
is
how
much
does
it
cost
to
like
what
what
damage
could
a
really
well-funded
adversary
do
to
your
system?
AD
Implementation
is
like
how
complex
is
it
to
build
and
reason
about,
and
also
implementation
talks
about,
your
standard
development
practices
like
do
you
have
good
security
hygiene
and
then
there's
environmental
security?
Environmental
security
is
basically
how
can
you
can
think
of
bridges
as
an
oracle
of
information
from
two
different
domains
and,
if
you
think
of
them
that
way,
then
you
have
to
ensure
the
quality
of
the
information
as
it
transfers
from
a
low
security
domain
to
a
high
security
domain.
AD
So
what
I
mean
by
that
is
like
if
flip-flop
chain
is
you
have
a
bridge,
that's
connecting
flip-flop
chain
to
ethereum
and
that
flip-flop
chain
is
51
attacked?
How
does
your
system
handle
passing
that
information
that
may
be
maliciously
malicious,
so
Economic
Security?
What's
your
price?
How
much
does
it
cost
to
corrupt
all
of
your
validators?
Basically,
the
only
great
way
to
kind
of
constrain.
This
risk
is
to
have
a
permissionless
and
diverse
validator
set.
AD
Otherwise
you
everybody
does
have
some
sort
of
bribery
prize,
so
a
natively
verified
Bridges
to
kind
of
break
them
on
their
Economic
Security.
You
have
to
corrupt
the
domain's
underlying
validator
Set
for
externally
verified
systems
you
have
to
corrupt
their
Bridge
validator
set
and
again
like
whether
or
not
that's
the
weakest.
Validator
set
depends
a
lot
on
the
chains
that
you're
connecting
and
then
optimistically
verified
systems.
There's
a
few
different
ways:
you
could
corrupt
the
economic
security
of
these
systems.
AD
The
first
is
that
you
bribe
all
of
the
Watchers,
which,
ideally
this
is
a
permission
listening
to
join.
So
if
you
can
do
that,
that
would
be
really
expensive
and
difficult
to
do,
and
you
wouldn't
even
really
be
able
to
dox
all
of
them,
but
also
you
could
censor
the
destination
domain
or
censor
the
home
domain
so
that
it
becomes
impossible
to
actually
submit
a
fraud,
proof
or
disconnect
transaction.
AD
So,
in
terms
of
like
where
all
these
system
ranks
native
is
probably
is
going
to
be
the
most
secure
for
Economic
Security,
followed
by
optimistic
and
external
and
again,
this
is
largely
dependent
on
the
permissionlessness
and
diversity
verifier
set
okay,
so
implementation
security.
How
simple?
Is
it
like?
Your
Bridges
already
have
a
massive
surface
area
because
they're
connecting
like
dealing
with
a
heterogeneous
environment,
so
those
dependencies
will
trickle
up
and
it's
something
that
you
have
to
deal
with.
AD
So
the
only
way
to
really
mitigate
that
that
type
of
implementation
risk
is
to
constrain
your
surface
area,
which
means
you
should
probably
talk
to
your
theoretical
physics,
friends,
because
they're
really
good
at
that.
But
implementation
security
is
not
just
how
simple
your
system
is.
It's
also
all
about
code,
hygiene,
all
about
development
practices,
all
about
security
mindset
like
do
you
Buzz
your
test.
You
have
audits
you.
What's
your
test
coverage?
Are
your
bug?
Bounties
live?
Have
you
done
war
games?
AD
You
can
also
constrain
this
implementation
Risk
by
building
your
systems
defensively
and
what
I
mean
by
that
is
integrating
things
like
rate
limits.
So
if
you're
a
bridge
and
somebody's
withdrawing
ten
dollars,
that's
probably
fine.
You
can
probably
let
that
happen,
but
if
somebody's
withdrawing
90
of
the
value
in
your
bridge
in
a
single
transaction,
maybe
you
want
to
add
some
delays
or
some
extra
verification
on
that,
so
that
people
can
react
appropriately
so
for
natively
verified
Bridges.
AD
They
are
pretty
complicated
because
you
have
to
deal
with
the
underlying
consensus
set,
and
so
you
really
need
a
unique
Bridge
implementation
for
each
domain
pair
that
you're
connecting
for
externally
verified
systems.
It's
really
nice
because
you
can
take
the
exact
same
system
and
put
it
on
pretty
much
any
domain.
The
complexity
comes
from
the
like
off-chain
coordination
between
the
verifier
set
anytime
that
you
have
to
have
a
coordination
between
multiple
actors.
It
becomes
more
complex
with
optimistic
systems.
AD
You
don't
need
that
off-chain
coordination
between
all
of
the
Watchers
and
so
that
they
really
have
an
advantage
in
terms
of
implementation
security,
so
yeah
optimistic,
wins
here,
followed
by
external
and
then
native
Bridges
actually
do
the
worst.
So
now
we're
talking
about
environment
security.
So
again,
like
bridges,
are
Oracles
of
information
from
one
domain
to
another,
and
you
need
to
make
sure
that
your
system
can
vouch
for
the
quality
of
that
information.
You
can
constrain
environment.
The
really
the
best
way
to
do
that
is
to
add.
AD
Off-Chain
checks,
like
51
attacks,
are
really
difficult
to
check
on
chain
and
you
want
to
be
able
to
add
equivalency
checks
to
and
delays
to
your
information
so
that
you
don't
respond
immediately
to
in
data
that
could
be
malicious,
so
natively
verified
systems.
These
happen
synchronously
as
soon
as
like
it
passes
consensus.
It
could
pass
through
the
mechanisms
of
natively
verified
Bridges,
which
means
that
if
there
is
a
51
attack,
you
don't
really
have
a
strong
defense
against
that
for
externally
verified
Bridges.
AD
So
these
checks
are
kind
of
treated
as
a
first-class
citizen,
so
yeah
optimistic
bridge
is
best
here,
external
and
then
native
so
woohoo
optimistic
Bridges,
like
probably
the
best,
but
that
doesn't
really
matter
that
much
because
that's
not
like,
where
we're
getting
attacked
the
hacks
that
we
see
the
bridge
hacks
that
we
see
they're
almost
all
at
this
implementation
level.
So,
in
terms
of
attack
difficulty,
it
requires
way
less
resources
to
be
able
to
exploit
the
implementation
of
a
bridge
and
like
exploit
the
implementation
risk.
AD
If
you're
going
to
do
an
economic
attack,
you're,
probably
going
to
need
a
lot
of
money
and
if
you're
doing
an
environmental
attacks
like
corrupting
the
validators,
well
you're
going
to
need
a
lot
of
money
and
probably
a
lot
of
know-how
as
well,
and
we're
not
seeing
any
of
those
types
of
attacks.
Those
are
pretty
rare.
AD
What
we're
seeing
all
the
time
of
these
implementation
Keys
the
one
the
one
exception
being
Ronin
Ronin,
is
like
a
multi-sig
bridge
where
they
have
some
number
of
signers
have
to
verify
all
the
transactions,
I
would
argue
and
those
keys
got
compromised.
The
bridge
got
drained
for
hundreds
of
millions
of
dollars.
I
would
argue
that
that
was
again
an
implementation
failure
in
guarding
your
keys
more
than
an
attack
on
the
economic
model
of
the
bridge.
AD
So
if
implementation
security
is
like
the
most
accessible
thing
for
us
to
solve
a
lot
of
that
comes
from
thinking
simply,
but
also
from
the
Decades
of
Prior
cyber
security
processes
and
research
that
we
have.
Why
are
we
still
having
so
many
hacks
and
the
reality
is,
like
security
doesn't
exist
in
a
vacuum.
AD
So
a
lot
of
the
trade-offs
that
people
make
when
they
actually
ship
Bridges
is
to
take
some
type
of
shortcut.
The
most
common
shortcuts
that
you'll
see
are
whitelists,
upgradability
and
centralization.
So
if
you're
lping
on
a
bridge,
that's
probably
going
to
be
gated
behind
a
white
list,
if
you're,
an
external
validator
of
those
oops,
sorry
have
those
gated
behind
whitelists
as
well.
There's
also
upgradability
upgradability
is
controversial.
AD
It's
not
clear
whether
it's
better
to
have
an
opt-in
or
an
opt
out
system
since
you'll
want
an
opt-out
system
to
fix
emergency
bugs,
but
you
want
an
opt-in
system
to
allow
projects
to
kind
of
change,
their
security
risk
at
their
own
at
their
Leisure.
But
most
of
the
time
the
upgrade
systems
that
are
in
place
on
all
of
these
bridges
are
just
instant
upgrade
by
an
admin
multi-sig,
which
obviously
kind
of
undermines
the
entire
security
model
that
most
teams
advertise
and,
quite
frankly,
it's
mostly
a
branding
exercise.
AD
And
then
you
also
have
elements
of
centralization.
That
means
like
possibility.
You
have
centralized
supporting
services,
so
in
bridges,
actually
fewer
running
your
own
node
or
running
your
own
node
is
just
as
important
as
like
securing
your
keys,
and
the
reason
for
that
is.
If
you
don't
run
your
own
node,
you
could
get
malicious
events
and
generally
as
you're
an
LP
like
most
bridges
function
by
watching
for
events
on
Source
chain,
validating
them
and
sending
them
out
on
destination
chain.
AD
And
if
you're
you
have
are
connected
to
a
malicious
node
provider,
then
that
event
is
incorrect
and
you
could
have
just
sent
them
a
lot
of
money.
So
these
are
all
things
that
common
shortcuts
that
bridge
projects
take
because
right
now,
they're
trying
to
de-risk
their
unknown
unknowns.
Like
is
this
even
the
best
way
to
pass
information?
What
are
the
RPC
qualities
like
on
the
domains
that
I'm
connecting
to
there's
a
lot
of
other
things
that
go
into
creating
a
secure
protocol?
AD
So
that
means
that
there
are
some
practical
considerations
that
aren't
the
most
tasteful
that
are
important
for
you,
as
a
user
when
you're
evaluating
your
security.
So
the
first
one
is:
is
this
my
life
now,
which
basically
means
you
have
to
understand
how
long
you're
exposed
to
the
risk
of
the
bridge?
AD
So
if
you
are
using
a
assets
that
came
from
a
default
Bridge,
not
even
the
default
Bridge
itself,
you
are
still
exposed
to
that
bridge
risk
if
you
are
using
or
lping
on
a
bridge
for
either
the
amm
or
just
as
a
liquidity
provider
of
some
other
type.
AD
You
really
will
be
exposed
to
the
risk
of
that
bridge
for
the
duration
of
the
time
that
you
are
lping,
if
you're
a
user
in
your
crossing
a
bridge
and
it's
not
the
default
Bridge,
so
something
like
hop
or
connects
you're
only
exposed
to
the
risk
while
you're
Crossing
another
one
to
check
is
like.
Where
are
your
receipts?
What
have
you
done
like
the
Lindy
effect
is
incredibly
powerful
in
bridges,
but
it
should
reset
every
time
that
there
is
an
upgrade.
AD
So
you
have
to
look
at
how
long
it
take
how
long
Bridges
have
been
securing
a
large
amount
of
money
and
that's
a
really
good
proxy
for
how
secure
it
is
because,
if
there's
a
lot
of
money
there,
it's
probably
an
appealing,
Target
and
so
people
have
probably
tried
to
hack
it
and
can't
that
being
said
just
because
it's
been
around
for
a
while,
doesn't
mean
there's
not
a
bug
in
it
and
then
the
other
one.
AD
This
is
like
the
most
unfortunate
to
have
to
consider
because
it's
kind
of
against
the
ethos
of
the
space,
but
because
Bridge
projects
take
these
shortcuts.
It
is
really
important
and
are
kind
of
running
on
training
wheels.
It
is
really
really
important
to
know
if
you
can
trust
the
Judgment
of
the
team.
Do
you
know
that
they
follow
good
development
practices?
AD
Do
you
trust
that
if
something
went
wrong,
they
would
continue
working
on
the
project
and,
if
you're
not
capable
of
evaluating
like
the
specific
development
processes
and
hygiene
of
the
team,
then
you
really
do
need
to
lean
on
social
signaling
for
other
people
who
would
vouch
for
that
who
do
have
more
knowledge?
It's
kind
of
unfortunate
that
that
that
that
that
ends
up
being
what
we
have
to
fall
back
on,
but
until
these
bridges
are
really
Standalone
systems,
that
just
kind
of
is
your
best
bet.
AD
M
Yo,
thank
you.
That
was
great.
How
do
you,
how
do
you
make
your
own
considerations
so
you're
talking
about
getting
some
shortcuts
regarding,
like
the
weighing
off
like
security
and
speed
like
time
to
deploy
time
for
time
to
production?
How
do
you,
how
do
you
weight
those
things
that
connects?
How
do
you
make
the
decision
of
say
centralizing
some
aspects,
for
example,
yeah.
AD
Well,
so
I
can
tell
you
exactly
what
our
shortcut
was
so
and
our
nxtpv
zero,
that's
kind
of
an
atomic
transfer
system
and
how
it
works.
Is
you
have
a
trans?
You
run
an
auction
process
and
then
LPS
can
bid
on
facilitating
your
transfer
users
select
the
winning
LP.
That's
great.
All
of
that
needs
to
happen
on
a
messaging
server.
We
use
a
centralized
messaging
server
because
figuring
out
how
this
would
work
in
the
wild
and
how
it's
like
kind
of
what
our
risk
to
a
business
was
figuring
out.
AD
Decentralized
messaging
was
not
high
on
that.
Like
decision
Matrix
priority,
it
just
wasn't
something
that
we
would
be
able
to
focus
on
I.
Think
like
as
we've
matured
as
a
project,
we've
started
to
kind
of
realize
that
it
is
really
important
when
you're
not
sure
about
the
entire
security
of
your
system,
because
you
have
no
Lindy.
It's
really
really
important
to
make
sure
that
there
are
some
controls
that
you
can
enact
like
pausing.
The
system
is
incredibly
important,
especially
as
it
increases
in
complexity.
M
AD
For
the
centralized
messaging,
we
asked
some
of
these
two
folks
if
they
would
recommend
lip
P2P
and
they
said
absolutely
not
and
so.
You're
like
okay.
S
So
you,
you
talked
about
the
dangers
like
how
you
lose
your
lindiness
when
you
upgrade
a
bridge
I'm
curious.
If
you
have
specific
ideas
about
like
the
testing
and
yeah
the
testing
procedures,
that
you
would
have
specific
to
upgrades
to.
AD
Make
sure
that
super
strong
super
strong
opinions
about
that
personally,
yeah
I
yeah
I,
like
at
the
very
least
you
should
set
up
a
hard
hat
or
forage
project
that
Forks
the
mainnet
URL
and
runs
a
bunch
of
fuzzing
and
unit
tests
against
the
upgrade
that
you've
performed
but
I.
Think
beyond
that,
like
that's
great,
you
need
to
have
a
separate
mainnet
test
bed
contract
environment
where
you
can
run
these
tests
and
then
you
need
to
do
some
fire
drills,
like
red
team,
blue
team.
AD
So
we're
gonna
do
our
first
one
on
our
upcoming
Fork,
probably
in
the
next
few
weeks
here,
but
we'll
give
them
like
a
two-week
time
frame
and
say:
okay,
sometimes
within
this
two
weeks
get
it
and
if
I
really
wanted
to
be
mean
I'd
be
like
do
it
while
I'm
asleep,
because
which
I
probably
will.
AD
AD
C
C
C
C
C
B
B
B
B
B
B
AH
AH
AH
Imagine
you
know
the
business
that
was
supposed
to
have
been
here
right,
so
I'm,
not
a
technical
person
I'm
supposed
to
take
a
technical
presentation,
so
bear
with
me
if
I'm
going
wrong
I'll
try
to
keep
it
as
clear
as
possible,
I'm
on
the
phone
with
them.
If
there
are
questions
at
the
end,
that
I
don't
know
the
answer,
I'll
call
them
up.
Those
guys
are
very
technical,
okay.
AH
So,
basically,
even
the
last
talk
was
about
securing
Bridges
and
stuff
like
that.
But
let
me
try
to
make
it.
Why
are
we
interested
in
bridges
what
is
making
it
so
attractive?
I
think
there
are
two
things
as
devs.
You
can
see
that
layer,
0
raising
135
million
cash
flow,
raising
25
million
no
marked
raising
22
million.
Now,
from
the
hack
side,
Ronin
Bridge
lost
600
million
last
year,
wormhur
or
losing
325
and
Harmony
Bridge
as
an
example
of
losing
100
million
right.
So
this
is
why
it
gathers
attention,
there's
so
much
money
involved.
AH
So
before
I
go
deep
into
the
talk,
the
idea
is
I'm
going
to
explain
just
basic
about
the
space
about
bridges
cross
chain.
Why
is
it
important
some
of
the
examples
out
there
and
then
some
of
the
hacks
that
happen
and
what
caused
those
hack?
Okay,
that's
the
the
general
idea
how
the
talk
is
going
to
go.
Fundamentally,
what
is
a
blockchain
if
there
are
people
who
know
this
is
out
here,
it's
basically
at
Ledger
and
what
does
it
store?
It
stores,
data
and
transactions,
data
and
transactions.
AH
As
long
as
you
can
move
them,
they
have
value
and
when
they
have
value,
there's
a
price
and
there's
an
exchange
and
there's
a
market
cap.
So
numbers
are
a
little
off
you're
only
at
950
billion
today.
But
let's
assume
the
market
cap
is
400
and
at
1
trillion
we're
at
450
billion
in
Bitcoin
200
billion
in
ether,
50
billion
binance
and
the
rest
of
them
make
the
market
cap.
So
basically
there's
value
across
different
chains
and
it's
fragmented.
That's
why
cross
chain
swaps
are
cross
chain.
Bridges
are
important,
they're.
Just
so.
AH
Basically,
blockchains
are
really
desperate
wall
Garden
Wall
islands
of
value.
So
you
have
two
islands.
If
you
can't
move
the
assets
across
these
islands,
you
can't
move
value
across
them.
Imagine
traveling
from
U.S
to
UK,
and
you
can't
use
your
money
over
there
kind
of
useless
right.
There's
a
restaurant
out
there
who's
willing
to
take
your
money
in,
but
you
you
don't
have
pound
with
you.
You
just
have
dollars.
AH
So
that's
where
you
need
something
in
between
like
an
ATM
machine,
Banks
or
credit
card
processing,
something
like
that
to
move
these
value
from
one
Island
to
the
other.
Fundamentally,
that's
what
a
cross
chain
Bridges!
You
have
some
assets
or
valuable
stuff
on
one
blockchain.
You
want
to
move
it
to
another
blockchain,
that's
a
bridge
when
you're
doing
a
swap.
AH
You
had
Solana
with
you
and
you
want
to
use
ethereum,
and
you
had
to
go
to
coinbase,
to
sell
your
Solana
to
USD
and
then
buy
ethereum
and
then
bring
it
to
your
app
imagine
doing
this
when
you're
traveling
imagine
you're,
you've
come
to
bogot
a
lot
of
you
come
from
other
countries
right.
Imagine
going
to
the
bank
changing
money
instead
of
just
using
your
credit
card
somewhere,
you
know
at
your
hotel
or
at
the
restaurant,
so
D
Phi
is
going
to
be
very
big.
That's
the
Assumption!
AH
Let's
assume
that
all
of
you
are
assuming
that
with
me.
We
are
all
going
to
replace
trade
fire,
the
traditional
Finance
one
day.
If
that
is
the
case,
this
piece
cross
chain,
swaps,
Bridges
or
cross
chain
communication
is
going
to
be
a
very
critical
infrastructure,
all
right.
So
fundamentally,
there
are
three:
there
are
multi
three
three
things
that
are
very
important:
you're
moving
between
proprietary
blockchains,
taking
an
example
is
moving
Solana
from
an
SLP
standard
to
a
binance,
smart,
smart
chain
with
a
bep20
how
about
transferring
assets
between
layer,
twos
between
arbitrum
and
optimism?
AH
If
you
want
to
do
that
today,
imagine
you
have
to
take
your
arbitrum
put
it
back
to
ethereum.
You
have
to
wait
seven
days,
then
you
have
to
move
it
to
optimism
right,
that's
what
that
is
the
friction
that
we
want
to
reduce
with
cross
chain
swaps.
So
generally,
there's
an
architecture
for
this.
You
are
you
you're,
transferring
information,
it
could
be
asset,
it
could
be
contract
calls
from
one
blockchain
to
the
other.
So
on
one
side
you
have
a
node
that
monitors
the
source,
gene
or
the
original
chain.
AH
We
call
them
the
validator
that
transmits
information
from
the
sourcing
to
the
destination
chain
in
between
there
are
checks,
and
there
are
checks
happening.
You
know
on
requiring
what
is
the
consensus
among
the
validators,
and
there
is
a
signature
and
eventually
the
validate
on
the
destination
chain
verifies
the
signature
and
issues
in
IOU.
This
is
typically
what
that
happens,
or
the
other
ways
you
can
send
to
a
liquidity
pool.
You
can
use
amms
and
do
this
process.
AH
So
I'll
now
talk
about
the
various
types
of
bridges
and
the
mechanisms
out
there.
One
is
the
proof
of
authority
Bridge
a
POA
Bridge.
You
have
a
small
set
of
actors
that
are
listening
to
events
on
the
source,
change
they
validate
them
and
they
relay
this
across
to
the
destination
chain.
Incentivization
and
slashing
mechanisms
ensure
the
Integrity
of
this
thing.
So
the
pros
are
that
there
are
few
validators,
so
it's
very
fast.
AH
You
can
easily
do
it,
but
the
cons
are
now
you've
introduced
Trust
on
these
few
validators
there's
a
collusion
possibility,
something
very
similar
is
a
POS
Bridge
or
the
proof
of
stake
bridge.
Now,
instead
of
one
node
you're,
giving
it
to
the
person
who
has
more
number
of
tokens
or
the
token
balance,
they
do
the
verification
and
signature.
What
are
the
cons?
The
security
depends
on
the
price
of
these
tokens.
AH
The
next
is
a
light.
Client
Bridge
example
is
a
Rainbow
Bridge,
so
a
smart
contract
with
a
ethereum
like
client
functionality
is
deployed
or
near,
and
a
smart
contract
with
near-line
contract
functionality
is
deployed
on
ethereum.
The
verification
is
done
by
both
chains,
calculating
the
Merkel
routes
and
verifying
it
its
headers
there's
no
need
of
a
validator.
Besides
the
miner,
for
both
the
chains
it
it
the
cons,
are,
it
requires
a
high
input.
It
has
a
high
implementation
cost
over
there.
AH
It
requires
smart
contract
development
to
hold
both
the
like
clients
on
both
the
blockchains
all
right.
So
there's
then
there's
an
ultra
light,
node
with
Oracle
or
Bridge
adapters.
It
does
not
keep
track
of
headers,
but
it
then
it
depends
on
oracles
and
relayers.
So
then
they
can
start
colluding.
That's
also
possible.
AH
The
other
option
is
we
do
chain
Bridges.
You
know
the
instead
of
validators,
you
have
a
chain
out
there.
Now
that's
an
elegant
solution.
When
you
take
it,
that's
truly
decentralized,
there's
a
dedicated
POS
Hub,
but
then
you
can't
do
middleware
logic
over
there.
So
that's
what
people
are
trying
to
solve
when
it
comes
to
chain
Bridges,
side
chains,
again
you're
connected
to
the
main
chain.
AH
All
those
movements
happen
quick
easy,
but
then,
when
you
want
to
do
between
other
blockchains,
it's
not
easy
over
there
different
kinds
of
bridges,
there's
one
as
a
custodial
bridge
wbtc
wbtc
is
bitco,
holds
the
custody
of
wbtc.
The
when
you
send
BTC
to
get
wbtc
bitgo
is
the
custodian,
a
decentralized
bridge
or
something
like
a
wormhole
uni
directional
bridge.
When
you're
doing
wbtc,
you
can
only
send
from
Bitcoin
to
ethereum.
You
can't
send
back
on
the
same
Bridge,
Wormhole
or
multi-chain
any
swap
those
were
the
multi-directional
bridges.
AH
So
fundamentally,
the
idea
is
when
you're
moving
across
These
Chains,
there's
a
lock,
mint
and
burn
mechanism
on
how
you
move
assets
across
chains.
So,
let's
assume
you
have
to
move
n
tokens
token
Z
from
blockchain
A
to
blockchain
B.
So
what's
happening
is
these
validators?
They
are
locking
it
on
there
on
the
source
chain
on
the
contract
on
a
and
they're
minting,
a
wrapped
version
of
that
on
on
B
So.
Eventually,
when
it's
replaced,
it
gets
burned
and
it
is
released.
The
original
tokens
are
released.
AH
The
problems
over
here
there
are
problems.
Also
it's
it's
not
like
it's
so
easy
as
it
sounds.
Okay
and
the
problems
are,
as
vitalik
said
now,
you're
dependent
in
on
the
fact
that
nobody
can
change
the
chain
on
a
so
even
the
previous
speaker.
She
had
a
better
graph
for
this.
How
what
you
put
over
there
vanish,
but
the
other
side.
You
got
it
when
you
come
back.
Your
original
stuff
is
not
there
all
right.
AH
So
when
you
burn
and
come
back,
your
original
should
be
there
to
get
any
benefit
out
of
these
we'll
talk
about
some
of
the
hacks.
That
happened
all
right,
so
the
Bali
hack
was
2021.
It
was
a
600
million
dollar
hack.
So
what
happened
over
there,
the
polyhack
or
Paulie?
There
was
a
master.
You
know
you
need
a
huge
liquidity
to
do
these
things
right.
That's
what
Paulie
had
a
large
there's
a
large
TBL,
and
there
was
a
master
wallet
that
contained
these.
AH
What
do
you
call
the
assets
and
it
was
based
on
Smart
contracts.
Large
amounts
for
the
large
liquidity
the
hack
was
possible
because
of
the
access
rights
through
these
eth
cross
chain
manager
and
heat
cross
chain
data.
They
got
access
because
of
the
you
know
the
bug
over
there.
They
got
access
somebody
outside
made
their
address
as
the
owner,
and
they
just
drain
the
funds
Wormhole
hack.
Here
it
was
a
little
different.
AH
What
happened
again,
this
was
this
year:
325
million
dollar
hack
a
deprecated
function
was
there,
they
updated
the
GitHub,
but
it
didn't
go
into
production
by
that
time.
The
hacker
knew
that
when
they
made
that
update
this
is
where
the
problem
is,
and
there
you
go
just
use
that
drained
it
out.
AH
It's
basically,
it's
like
you
had
at
that
point.
In
the
Wormhole
case,
you
had
issued
think
of
it.
Gold
certificates,
you're
issuing
gold
certificates,
hoping
that
there's
gold
under
the
Vault.
What?
If
there's
no
more
gold
under
the
world
and
people
are
coming
back
with
those
certificates
in
the
Wormhole
case,
you
know,
obviously
that
was
compensated
by
jump
crypto,
and
this
is
just
showing
what
really
happened
over
there.
The
root
cause
was,
the
signature
was
not
set.
Okay.
AH
Another
example
is
the
Ronin
hack
again
2022,
600
million
dollar
hack,
it's
more
realistically
here
it
was
a
web
2
issue.
So
there
are
two
kinds
of
security
issues.
We
can
talk
about.
There's
a
web
2
issue
and
there's
a
web
tree
issue:
smart
contract
hacks.
That's
a
web
3
issue.
Now
here
what
happened?
Was
they
had
kind
of
nine
validators
and
four
of
them
was
with
Sky
Mavis,
the
guys
who
developed
the
game?
What
happened
they
had
given
the
signature
to
the
sky
Mavis
team
a
year
ago
forgot
to
take
that
out.
AH
This
is
how
at
least
I
read
about
the
problem
was
somebody
working
over
there.
They
were
given
a
job
offer.
I
was
very
excited,
I
think
they
gave
him
three
times
what
he
was
getting
paid.
They
sent
him
a
PDF
to
sign.
You
know
he
clicked
through
the
PDFs
and
the
keys
were
gone
now
they
have
control
of
four
of
the
nine
validators
and
the
Dao
and
boom
600
million
dollars,
mostly
in
ether,
was
gone.
AH
So
the
funny
thing
here
was
for
close
to
a
week.
They
did
not
even
know
that
this
was
happening.
At
least
most
of
the
other
ones,
there
was
somebody
trying
to
find
it
or
knew
about
it,
and
here
the
hackers,
the
funny
thing
was
they
even
shorted
axi
and
the
wrong
tokens.
They
got
liquidated
because
it
didn't
go
down.
AH
So
you
know,
but
still
money
is
gone.
Nomad
hack
was
something
like
a
decision
that
they
made.
They
gave
up
security
for
Simplicity,
basically
the
like
clients.
They
decided
not
to
do
that.
When
the
update
was
done,
a
new
update
was
done,
they
could
spoof
transactions
or
fake
them
withdrawing
funds
which
are
not
theirs,
and
the
Noma
attack
was
the
funny
thing
was
after
some
time
anybody
could
hack
them.
You
could
do
it
yourself
and
they
were
the
white
hackers
who
helped
to
take
around
36
million
was
got.
They
proceed
back
total
I
think.
AH
Eventually
the
loss
was
150
million.
Initially
it
was
190.
I.
Think
36
came
back
here.
You
go
the
Fey
hack,
80
million
dollar
hack.
That
was
a
re-entrancy
bug
now.
These
are
all
very
now
nowadays,
re-entrancy
like
it's
like
four
years
ago.
You
didn't
know
about
the
re-entrance,
or
most
people
didn't
know,
but
nowadays
you
have
to
know
what
were
the
previous
hacks.
So
knowing
about
these
things
helped
the
Beanstalk
hack
again.
Here
it
was
Flash.
Loans
were
used
to
accumulate
the
governance
protocol
and
then
the
once
he
got
enough
tokens.
AH
He
just
put
a
proposal
saying
that
donating
funds
to
the
Ukraine
you
know
war
and
took
off
with
all
the
collateral,
so
I'm
just
planning
the
different
kinds
of
hacks
here
so
I,
don't
know
who
who
put
the
statement
out
there.
So,
if
you're
trying
to
create
a
bridge
between
and
different
cryptocurrencies
there's
a
goo
guy,
I
think
the
complexity
of
that
is
N
squared
so
which
means
that
there
are
N
More
chances.
So
there
are
way
more
bugs
that
can
happen
over
here
than
where
you
started.
AH
So
some
of
the
things
that
we
can
look
over
here
are
coding
practices
right
first
thing.
Obviously
you
should
know
the
web
2
security
stuff,
like
social
engineering,
phishing
running
a
malware,
spyware,
protecting
your
keys,
fundamental
things.
You
can't
assume
that
you're
in
web
3,
you're,
forgetting
all
the
web
2
stuff,
definitely
have
to
do
that.
Then
don't
let
a
regular
developer
go
and
code
a
D5.
You
know
blockchain
smart
contract,
where
you're
hoping
to
get
billions
of
you
know
dollars
into
that
contract,
because
that's
that's
really
like
I've
put
the
exam.
AH
AH
So
there's
a
paradigm
shift,
that's
happening
earlier.
We
just
had
one
code.
It
was
on
on
your
server.
Now
this
is
distributed.
It's
going
around
everywhere.
It's
it's!
A
total
paradigm
shift,
so
common
set
of
problems.
You
should
know
as
a
developer.
You
should
know
the
common
set
of
problems
like
re-entrancy,
integer,
overflow
and
again,
when
you're
trying
to
do
an
update.
You
know
that
there's
a
problem
and
you're
going
to
do
an
update
on
a
GitHub
before
it
goes
into
production.
There's
a
small
window.
AH
You
should
know
that
the
hackers
out
there
are
also
waiting
to
Tamper
on
that
some
of
the
other
things
you
know
typos.
You
know
uninitialized
implementation
contracts,
like
proxies
people
have
forgotten
to
do
to
do
that
and
an
attacker
has
come
and
taken
that
rounding
arrest,
unsafe
casting.
Then
there
are
smart,
smart
wallet,
attacks,
there's
Merkel
proof
mishandling.
All
these
things
could
be
prevented
like
if
you're
doing
enough
number
of
tests,
whether
it's
unit
functional,
then
formal
verification,
fuzzing
plenty
of
documentation,
and
then,
on
top
of
that,
you
give
it
for
audit.
AH
Those
of
you
who
are
in
the
development
space
out
here
I
would
seriously
say,
consider
an
auditor
job
because
most
of
the
guys,
the
bridges
that
I
know
they
are
paying
a
ton
of
money
to
Auditors.
Despite
having
audit
people
on
their
team,
they
are
running
these
contracts
through
multiple
Auditors
I
hear
right
now
it's
twenty
thousand
dollars
to
eighty
thousand
dollars
per
week
for
a
security
audit
engineer
per
week.
So
imagine
there's
a
bridge
out
there
or
D5
projects
out
there.
AH
AH
There's
going
to
be
hacks,
it's
just
it's
going
to
happen,
because
projects
are
trying
to
scale
speed,
they're
using
speed
to
try
to
get
users
as
quick
as
possible,
so
they're
making
decisions,
sometimes
that
this
it
should
have
taken
much
longer
so
now,
but
there's
one
thing,
though:
the
hacking
of
large
amounts
is
easy.
Maybe,
but
taking
it
out
is
not
that
easy,
because
now
you
have
chain
analysis,
elliptic
and
all
those
guys,
they're
tracking
it
exchanges
are,
you
know
Banning
them.
AH
Tornado
cash
is
being
bad,
so
there
are
a
lot
of
things
that
help
you,
but
that
doesn't
mean
that
you
should
not
take
care
of
your
code.
Okay,
so
keep
in
mind
in
2013
the
exchanges
were
being
hacked.
It's
just
that
right
now,
it's
the
bridges,
because
the
surface
area
for
them
to
attack
is
very,
very
large.
That's
the
main
thing
main
thing
is:
how
do
you
mitigate
these
things
and
what
is
your
response
once
this
happens?
AH
Obviously,
as
mitigation
part,
you
know,
do
your
code.
Well,
then,
you
do
audits,
front
bug,
bounties,
but
always
remember.
If
you
lose
money
on
your
wallet
or
your
smart
contract,
the
auditor
is
going
to
lose
nothing
he's
just
going
to
lose
its
reputation
end
of
the
it
is
your
project.
The
project
is
not
the
Auditors,
so
you
can
com
try
to
compartmentalize.
You
can
prevent
contamination.
AH
What,
if
it
happens,
how
do
you
respond
quick
enough?
There
are
multiple
times
where
these
white
hackers
have
contacted.
The
teams
out
there
saying
that
something
is
happening
to
your
contract
and
the
support
staff
said:
oh,
nothing,
we're
fine
and
all
their
money
was
gone.
I
I,
don't
have
those
tweets
with
me,
but
you
can
check
it
out
and
your
monitoring
systems
should
be
quick
and
you
should
have
some
kind
of
reporting
guidelines
once
this
happened.
What
are
you
going
to
do
as
a
team?
How
are
you
going
to
protect
yourself?
AH
How
are
you
going
to
bring
your
chain
down
if
you
can?
Is
there
some
kind
of
kill
switch,
because
a
lot
of
these
things
are
centralized?
So
basically,
Bridges
have
Pros
you're
bringing
collateral
cross
chain
you're
getting
scalability
you're
bringing
efficiency.
The
cons
are,
you
are
introducing
some
form
of
trust.
The
trustless
part
is
going
away,
so
this
space
is
going
to
grow
mainly
because
of
these
things.
So
much
money
money
has
to
move
and
a
lot
of
ways
to
attack
these
contracts.
AH
So
both
sides,
developers,
hackers
and
PCs-
are
going
to
invest
in
the
space
because,
just
like
think
of
it
in
the
real
world,
just
like
you
have
ATMs
banks,
credit
card
processing
machines,
bridges
are
are
a
very
big
thing.
AH
I
guess
everybody's
being
nice
to
me
saying
they
think
that
you
know
if
the
guy
doesn't
know
anything.
So,
let's
not
complicate
it
all
right!
There's
somebody
is
out
there
a
mic
over
there
please
I
can
I
can
try
to
answer
some
of
the
things,
but
if
I
can't
I'll
tell
you
guys
I'll
take
your
name
I'll
contact
the
guys
who
made
the
protocol
and
get
back
to
you
for
sure.
F
F
AI
AH
Got
it
I
think
the
best
is
first
learn
smart
contract
or
solidity
from
let's
say:
Patrick
Collins
is
a
YouTube.
Video
dap
University
is
out
there
and
then
securium
is
a
good
place.
They
have
a
boot
camp
and
they
have
a
lot
of
tests,
quizzes
and
stuff
which
they
go
through
all
the
possible
problems
that
you
can
face,
and
there
are
multiple
challenges
out
there.
Ethernet
challenge:
there's
ethernet
they're
plenty
like
that.
I
forgot
each
of
the
names
where
I
can
get
you
get
it
out
for
you.
AH
Okay,
that's
a
start,
learn
solidity.
Next
thing
is:
go
to
securium
and
find
out
how
they
do
and
that's,
as
I
said,
there
are
at
least
10
jobs
for
every
one
security
guy
out
there,
especially
in
the
web
3
space
and
it's
remote.
You
can
stay
at
your
home.
You
can
be
on
the
beach.
You
can
do
it
too
questions
over
here,
yeah,
that
is
a
mic.
N
Yeah,
like
the
the
the
perspective,
was
pretty
bleak
when
you
talked
about
like
end
to
end
like
the
end-to-end
complexity
of
like
bridging
all
kinds
of
bridges,
but
then
we're
here
at
the
ethereum
Devcon
and
we
know
like
the
Roll-Ups-
are
the
way
to
scale,
so
we
want
to
have
actually
a
thousand
yeah
of
these
l2s
right.
So
what
is
your
perspective
on
that?
How
are
we
going
to
solve
this
issue
so
initially.
AH
For
any
technology,
so
how
many
exchanges
are
being
hacked
today?
They're,
not
you
know
you
don't
say
coinbase
or
binance
being
hacked
on
a
daily
basis
right,
but
if
it
was
2013
literally,
every
exchange
was
being
hacked
right.
Everybody
so
same
thing
with
D5
or
Bridges.
It's
new
when,
when
did
bridges
come
into
being
it's
pretty
much
only
two
years
or
one
year
and
everybody
and
you
have
multiple
layer,
one
blockchains
out
there
and
you're
trying
to
connect
to
these
things.
AH
What
what
are
the
number
of
years
of
experience
to
somebody
who's
coding?
These
right
majority
of
it
is
one
to
two
years.
You
don't
have
four
years
six
year,
people
who
like
when
you
when
you're
building
your
NASA,
you
know
space,
shuttle
or
you're
doing
some
C,
sharp
or
C
plus
plus
code
Java
code.
There
are
guys
who
have
been
doing
it
for
20
years,
who
know
the
formal
methods
and
stuff
like
that,
so
those
problems
will
be
solved.
It's
like
the
buggy
and
the
car.
Okay,
the
car
was
initially
was
a
bad
technology.
AH
It
was
slower
than
the
horse,
but
technology
improves.
They
fix
those
kings.
The
wheels
were
flying
off,
you
flattened
the
roads,
you
make
better
Wheels,
you
make
better
shafts,
all
those
will
be
fixed,
so
the
future
is
not
Bleak.
The
future
is
really
good.
More
money
will
come
in
as
devs.
There's
there's
going
to
be
plenty
of
opportunity
now,
as
the
project
owner
who's
doing
one
of
these.
It's
it's
really
dicey
right
now,
because
you
don't
want
to
get
hacked
I
I
know
the
router
protocol
guys
they're
everyday
scared.
AH
They
keep
their
TV
at
low
because
once
the
tvl
becomes
high
you're
a
Honeypot
like
everybody
wants
to
attack
you
if
your
tvl
is
low.
You
know
that
this
all
the
great
hackers
are
not
so
interested
in
your
tvl,
which
is
low,
they're
thinking
of
high
Capital
efficiency
by
keeping
the
TV
at
low.
That's
how
they
are
trying
to
do
it.
AC
Hi,
can
you
hear
me
yep
yep
I
can
okay
great,
so
I
was
wondering
on
that
scenario
that
you
describe
that
the
developer
he
got
a
contract
like
a
PDF
contract
with
a
virus
and
took
over
his
nine
keys
and
therefore
the
bridge
Jesus
Christ
that
that
just
made
my
palm
sweat
I
just
spoke
about
that.
So
it
I
would
like
to
understand
a
bit
more
about
that
case
like
he
had
the
keys
in
his
computer
just
lying
around
there.
How?
How
did
the
hacker
extract.
AH
That
it's
there
in
the
computer,
it's
not
like.
He
had
it
in
a
sand.
It's
in
the
computer
that
you're
giving
access.
Literally,
so
imagine
you
get
these
PDFs
nowadays
you
can
sign
your
PDF.
It
was
a
job
offer
right,
so
somehow
they
knew
that
this
was
the
guy,
so
they
could
get
into
the
system
they
just
have
to
get
into
the
system.
Because
it's
connected
right,
a
job
offer
came
well,
you
know
they
did
interviews.
AH
They
were
formal
interviews
done
all
those
it
looked
very
legit
and
then
you
get
a
PDF
saying
you
know
you
got
the
call
saying:
hey
I'm,
sending
you
the
job
offer
you
just
click
on:
it
click
the
signs,
you're,
not
expecting
it
right.
So
there
it's
not
really
your
web
2,
the
web
3!
That's
a
problem!
It's
a
web
2
that
has
failed
so
both
have
to
be
considered
today.
AH
Definitely
they
shouldn't
they
shouldn't
have
gave
it
to
a
guy
who
who
had
four
validators
with
them?
No
guys.
Thank
you.
So
much
time
is
up
so
I'm
getting
down.
B
B
B
B
B
B
B
B
B
B
B
C
AJ
My
name
is
Janice
and
I'm:
a
smart
contract
auditor
I
work
for
sense
security
and
for
the
past
five
years
with
State
security,
we
have
secured
some
of
the
most
famous
D5
protocols,
and
sometimes
we
find
very
interesting
attack
vectors
as
the
one
I'm
going
to
describe
today.
Actually,
this
attack
was
found
by
a
colleague
of
mine
named
Canon.
So,
first
of
all,
why
should
we
care
about
this
attack?
Why
this
attack
is
so
important?
So
it's
actually
quite
a
quite
novel
attack.
AJ
Not
many
people
know
about
this
and
it's
often
neglected
by
both
Auditors
and
Developers.
So
this
attack
is
based
on
the
interaction
between
different
protocols
and
these
interactions
get
more
and
more
popular.
Since
you
know
we
build
based
on
these
defined
blocks.
What
makes
this
attack
more
interesting
is
that
it
actually
affected
protocols
that
integrate
with
curve
Finance
one
of
the
most
famous
expenses
out
there
and,
as
a
matter
of
fact,
the
total
funds
that
were
at
risk
were
more
than
100
million.
AJ
So
we're
talking
about
a
lot
of
money
here,
okay,
so,
first
of
all
what
is
re-entration.
So
are
you
interested
takes
place?
One
an
execution
of
a
smart
contract
is
interrupted
and
the
state
has
not
been
fully
updated
and
the
control
is
passed
to
another
smart
contract,
which
can
then
call
again
a
function
of
the
smart
contract
whose
State
hasn't
been
finalized
and
up
until
now
the
traditional
re-entrancy
was
concerned
only
with
entry
points
that
modify
the
state.
But
as
we
will
show,
this
is
not
the
case
here.
AJ
So
this
can
be
easily
fixed
and
people
deal
with
this
problem
by
introducing
this
non-rental
modifier.
So
if
we
visit
the
same
function
again,
we
cannot
call
withdrawal
again
when
we
receive
a
data,
because
the
lock
is
true
and
the
whole
transaction
will
fail.
However,
nothing
prevents
the
malicious
user
from
making
a
call
to
another
contract
which
reads
the
state
of
this
contract.
AJ
AJ
So,
let's
get
to
to
care
and
what
happened
there,
as
you
know,
is
a
decentralized
exchange.
There
are
many
pools
in
curve.
The
pull
that
was
affected
by
this
attack
was
the
a
pool
that
contains
native
ether
and
staked
ether
and,
as
you
might
know,
users
are
liquid
providers,
they
can
add
liquid
to
a
pool
and,
of
course
they
can
remove
liquidity.
So
what
happens
when
users
remove
liquidity?
Well,
first,
the
lp
tokens
they
hold
is
burned.
AJ
So
we
can
think
that
the
total
supply
of
the
lp
token
is
reduced
and
then
one
by
one
the
tokens
are
sent
to
the
user
and
the
first
token
that
is
sent
is
native
ether.
So,
upon
receivable
of
this
native
ether,
a
user,
a
malicious
user
has
the
opportunity
to
call
an
arbitrary
to
make
an
arbitrary
call.
Of
course,
I
cannot
call
a
curve
because
it's
protected
by
a
non-render
modifier.
AJ
However,
what
they
can
do
is
they
can
call
make
a
call
to
another
protocol
that,
for
that
reads,
the
state
of
this
pool
and
how
protocols
usually
read
the
state
is
by
using
this
get
virtual
price
function
that
I
have
down
below.
AJ
So,
let's
inspect
this
a
little
bit,
so
the
get
virtual
price
depends
on
this
D
factor
which
depends
on
the
balances.
Remember
we
have
only
updated
the
balance
of
the
ether,
but
not
the
balance
of
the
state
either
and
also
depends
on
the
token
Supply
and
remember
we
reduced
the
token
Supply.
So
what
we
achieved
here
is
we
essentially
pumped
the
this
get
virtual
price,
so
this
function
is
used
to
give
an
approximation
of
the
value
of
the
lp
token.
So
imagine
that
we
have
a
protocol
that
holds
these
LP
tokens
during
this
attack.
AJ
The
price
of
the
lp
token
is
pumped,
and
then
the
protocol
will
think
that
it
holds
more
money
than
it
should
so
to
wrap
it
up.
Read-Only
entrance
is
still
a
real
interest
in
the
sense
that
the
storage
is
the
storage
update
is
not
fully
finalized,
but
the
big
difference
is
that
we
read
the
state.
We
don't
try
to
access
a
function
that
modifies
the
state
of
the
function.
AJ
So
how
can
we
prevent
this
attack?
So
one
way
is
to
to
make
this
lock
that
I
showed
you
before
in
the
non
rental
modifier
to
make
it
public.
This
works
for
new
protocols
that
you
know
are
being
developed,
but
what
can
we
do
for
all
protocols?
Well,
the
thing:
the
solution
that
we've
seen
to
be
more
efficient
is
when
you
try
to
read
the
state
of
a
smart
contract.
First
try
to
call
a
function
that
is
non-reactor
protected.
AJ
B
AB
My
name
is
torgen
I
also
work
at
chain
security
and
today
I'm
going
to
be
talking
about
what
I
call
Future
block
Mev
in
proof
of
stake.
So
what
the
hell
is
future
block
Mev
supposed
to
be
to
understand
that
first,
we
have
to
talk
about
block
production
and
how
it
changed
with
the
merge
that
happened
a
couple
weeks
ago.
AB
We
use
the
randow
value
together
with
the
current
validator
set
to
do
this,
and
that
means
that
you
can
always
know
all
the
block
proposers
for
the
current
Epoch
and
for
the
next
epoch
and
since
two
epochs
and
ethereum
take
about
12
minutes.
That
means
that
if
you
are
a
validator
on
ethereum,
you
will
know
up
to
12
minutes
ahead
of
time
when
you
will
actually
be
the
one
that
is
able
to
produce
a
block.
AB
So
now,
what
do
you
do
with
this
information?
This
is
what
I
call
Future
block
Mev.
AB
AB
So
if
you
know
that
in
some
block
n
plus
one
you
are
going
to
be
controlling
that
block,
you
can
do
some
weird
stuff
in
the
blog
before
that
in
Block
n,
which
you
wouldn't
do
usually
so
one
example
of
that
would
be
that
if
you
want
to
do
an
oracle
manipulation
on
uniswap,
the
way
that
you
do
that
is
you
buy
some
asset
like
here.
We
have
some
asset.
AB
That
is
worth
one
and
then
you
buy
enough
of
that
to
let's
say
move
it
to
six
and
then
the
uniswap
Oracle
will
always
record
the
price
in
between
two
blocks.
So
it
will
record
this
price
of
six
at
the
end
and
we'll
take
that
into
its
average
that
it
reports
and
now
usually
this
would
be
very
expensive
to
do,
because
everyone
would
see
that
this
price
is
incorrect.
AB
So
there's,
obviously
a
really
big
Arbitrage
opportunity
that
somebody
could
take
to
like
sell
this
asset
at
a
higher
price
than
what
it
is
actually
at.
And
that
means
that
for
the
attacker
this
would
be
really
expensive.
But
because
now
we're
assuming
that
the
attacker
is
actually
the
block
producer
for
Block
n
plus
one,
they
can
just
put
their
own
transaction
at
the
very
beginning
of
the
block
n
plus
one,
and
they
can
guarantee
that
they
themselves
are
going
to
be
the
one
that
takes
this
Arbitrage
instead
of
anybody
else.
AB
So
essentially
they
are
able
to
hide
the
Mev
from
the
other
Searchers,
and
here
we're,
assuming
that
there
is
some
mechanism
in
which
they
can
make
that
first
transaction
in
Block
n,
without
going
through
the
public
mempool.
So
maybe
they
put
it
like
through
flashbots
or
something,
and
that
means
that
people
will
only
see
the
transaction
on
chain
at
the
point.
AB
Where
it's
already
too
late,
because
the
next
block
is
going
to
be
produced
by
the
attacker
and
nobody
is
going
to
have
any
time
to
to
react
before
that
happens,
and
so
one
example
of
what
you
could
do
is
if
there
was
a
lending
protocol
that
used
such
a
uniswap
Oracle,
you
might
be
able
to
manipulate
it
enough
to
get
some
to
get
something
into
the
liquidation
level
where
it
can
get
liquidated,
but
it
wasn't
able
to
before
and
then
that
liquidation
will
be
available
in
Block,
n
plus
one
and
again,
because
you
control
it.
AB
No
other
Searcher
is
going
to
be
able
to
compete
with
you
for
it,
because
you
can
just
put
your
transaction
like
in
second
position,
for
example
in
that
block.
So
then
you
can
trigger
a
liquidation
without
having
to
compete
with
all
the
other
Searchers
out
there.
AB
AB
So,
for
example,
you
can
use
it
through
doing
manipulations
or
creating
Mev
and
hiding
it
like
I,
said
here,
but
you
could
also
imagine
that
you
could
maybe
sell
future
blog
space
and
guarantee
that
to
people
or
you
could
even
incentivize
people
to
create
a
lot
of
Mev
in
a
block
that
you
will
control
like
you
can
imagine
if
there's
some
nft
project,
they
might
not
care
exactly
in
which
block
they're
going
to
be
launching.
AB
So
you
could
just
tell
them
to
launch
in
the
block
that
you
create
and
then
all
of
the
gas
that
is
going
to
be
spent
on
minting
those
nfts
early
is
going
to
be
in
your
block
instead
of
somebody
else's
yeah,
so
I
wrote
a
paper
on
Oracle
manipulation
and
a
blog
post
on
how
that
changes
after
the
merge.
So
if
you
guys
are
interested
in
learning
more
about
the
Oracle
manipulation
side
of
it,
I
highly
recommend
checking
it
out
and
yeah.
That's
it.
B
C
Just
because
we're
running
a
bit
ahead
of
schedule
and
I
don't
want
people
to
miss
out
on
the
next
set
of
talks.
Yeah.
B
A
D
The
goal
of
the
underhanded
solidity
contest
is
to
provide
harmless
or
unsuspicious
looking
smart
contracts
with
hidden
bugs
or
pitfalls,
thereby
exposing
weird
behavior
and
solidity
in
a
fun
way.
Let's
Jump
Right
In,
here's
an
excerpt
from
the
solidity
docs.
What
it's
basically
saying
is
the
evaluation.
The
evaluation
order
of
Expressions
is
not
specified.
If
function,
f
takes
two
arguments
which
are
further
function,
calls
to
functions,
G
and
H,
it's
unclear
in
which
order
they
are
evaluated,
I,
don't
function,
G
is
a
related
first
or
function.
D
D
Let's
consider
this
example,
what
let's
say
we
call
a
function
with
an
argument
of
two:
what's
the
correct
result
here,
is
it
four
or
five?
Well,
it
depends
on
the
evaluation
order
and
it's
not
really
specified
for
the
solidity
compiler.
This
is
not
unique
to
solidity.
Insufficient
specification
to
of
expected
Behavior
can
be
found
in
all
kinds
of
different
programming
languages.
A
big
headache
for
everyone
involved.
D
D
Yes,
most
of
the
time
evaluation
order
is
as
expected,
from
Left
of
right,
but
not
always.
First,
two
examples
are
the
opcodes,
add
mod
and
mule
mode,
and
here
the
evaluation
order,
surprisingly,
is
from
right
to
left.
So
if
we
evaluate
F
of
2,
it
first
evaluates
a
incremented
by
one
and
only
later
evaluates
the
first
argument,
which
results
in
add
mod
with
argument:
three
two
instead
of
2
2
as
you
might
have
expected.
D
Interestingly,
this
is
actually
documented
in
the
solidity,
however,
not
where
you
expect
in
solidity.
There
are
currently
two
ways
on
how
code
can
be
compiled:
the
default
code
generation
and
the
new
code
generation
via
the
UL
IR
pipeline
in
in
the
documentation
describing
the
Euro
pipeline.
It's
actually
documented
that
here
the
evaluation
order
will
no
longer
be
from
right
to
left,
but
also
left
right.
D
The
most
interesting
one
is
the
order
of
evaluation
inside
events.
This
one
is
really
special.
The
parameters
are
evaluated
in
a
bizarre
order.
First,
the
indexed
parameters
are
evaluated
from
right
to
left.
Then
the
remaining
parameters
are
evaluated
from
left
to
right
wow,
who
knew
that
with
solidity
death.
Has
this
in
mind
when
coding?
No
one
right,
this
can
lead
to
really
strange
or
unexpected
Behavior,
and
this
is
what
tenant,
leveraged
and
used
for
his
submission
to
the
underhanded
solidity
contest.
D
D
D
Old
admin
fee
is
called
first,
which
execute
claim
fee
this
by
and
distributes
the
fees
based
on
the
old
fee
amount
to
the
liquidity
provider
before
calling
set
new
admin
fee,
which
updates
the
admin
fee
to
the
new
admin
fee,
but
remember
what
we
just
learned
before
indexed
events
are
evaluated
from
right
to
left
so
actually
set
admin
fees
evaluated
first,
so
the
fee
is
updated
and
only
afterwards
retire.
Old
admin
fee
distribute
the
liquidity
fee
to
the
liquidity
liquidity
providers
based
on
the
new
fee,
really
surprising.
D
So
one
important
thing
to
mention
here:
the
solidity
compiler,
as
that
has
two
ways
to
compile
called
the
default
way
and
the
new
way
using
the
Yule
IR
pipeline
in
the
Yule
IR
pipeline.
This
is
no
longer
true.
They
are
the
function.
Evaluation
order
is
strictly
from
left
to
right.
However,
by
default,
the
solidity
compiler
uses
the
old
code
generation,
but
this
may
change
at
any
time
in
the
future.
B
C
C
All
right,
hello,
everyone,
so
we,
our
next
talk,
will
be
at
5
30.,
and
it's
going
to
be
the
last
30
35
minute
set
of
talks.
How
excited
are
you
all?
Are
you
guys
even
alive
yet
the
whole
day
of
the
first
Devcon
in
three
years,
pretty
exciting?
Actually
yeah
next
set
of
dogs
are
more
about
so
far
early
in
the
day,
this
talk
was
more.
This
room
was
more
about
layer,
twos
and
then
progressively.
C
We've
shifted
more
towards
the
security
side
of
things,
and
then
there
are
more
talks
about
layer
tools
in
the
other
rooms
as
well,
so
I
hope
it's
been
as
good
of
a
day,
one
for
Defcon
as
husband
for
me,
we
are
for
now
please
stay
seated
and
wait
for
the
next
talk.
I
think
we
only
have
two
more
talks
before
day.
One
is
over,
and
then
after
that
don't
forget,
we
have
something
happening
on
the
ground
floor.
C
It's
called
the
Shiva
Lounge,
where
we'll
have
nice
chill
music
just
to
de-stress
and
uncompress
everything
that
we've
learned
or
networked
about
this
whole
day,
yeah
and
also
Defcon
after
dark,
is
a
thing.
So
this
venue
will
remain
open
until
11
pm
today.
So
if
you
want
to
meet
up
with
your
colleagues,
just
chill
not
go
to
a
Ravi
style
event,
because
you
have
a
talk
tomorrow,
you
can
just
relax
here.
C
C
C
Q
Q
Q
C
AK
AK
Good
afternoon
everyone,
so
my
name
is
Jorge
arse
I
am
a
blockchain
and
cryptography
researcher
at
nethermind,
and
today,
I
want
to
tell
you
guys
about
Shamir
secret
sharing
with
no
ID
numbers,
but
before
we
get
into
the
problem
we're
trying
to
solve.
AK
AK
So,
let's
suppose
you
just
got
this
great
news.
You
just
got
the
private
key
of
a
wallet
that
is
holding
a
thousand
ether.
Here's
the
private
key
now
do
not
actually
input
this
into
metamask
or
you
will
be
very
disappointed.
Okay
for
secure,
long-term
storage
of
this
seed
freeze,
you
want
to
do
the
following,
because
it's
a
lot
of
money
right,
so
you're,
going
to
split
the
key
into
several
12
word:
seed
phrases
such
that.
If
you
have
two
of
those
C
traces,
then
you
have
enough
information
for
reconstruction.
AK
Furthermore,
you
want
the
secret
to
be
accessible.
Even
if
one
of
the
pieces
in
which
you
like
split
the
information,
gets
lost
and
there's
a
third
property,
actually
that
I'm
mentioning,
which
is
you
would
like
it,
so
that
an
attacker
that
has
two
of
the
pieces,
no
I'm,
sorry,
if
an
attacker
has
one
of
the
pieces,
but
not
two,
they
cannot
gain
any
information
about
your
secret
whatsoever.
AK
So
you
decide
that
you
will
create
three
pieces
such
that
you
need
two
of
them
to
reconstruct
the
secret
and
technically
we
call
this
a
2-3
threshold
scheme.
This
is
what
you're,
after
okay.
So
how
does
this
go?
This
is
an
old
algorithm
created
by
Shamir
in
1979.
AK
We
start
with
the
seed
phrase,
and
the
first
thing
we're
going
to
do
is
we're
going
to
turn
this
into
a
number.
This
is
in
binary.
What
we
did
is
we
took
bit
39
2048
word
dictionary
and
we
depended
on
the
position
of
these
words.
In
that
dictionary,
we
assign
a
binary
binary
number
to
each
of
the
words
once
you
have
that
you're
going
to
take
a
good
old,
X,
Y,
plane
and
you're
gonna
take
the
secret.
AK
This
is
a
number.
After
all
and
you're
going
to
place
it
on
the
y-axis
sort
of
like
as
an
intercept,
so
that's
stage
one
after
that
you're
going
to
take
a
random
straight
line
that
passes
through
the
secret.
Why
a
straight
line,
because
this
is
the
simplest
example
where
you
only
need
two
pieces
for
reconstruction?
AK
If
you
wanted
something
more
complex,
you
would
be
using
like
a
parabola
or
a
higher
order,
polynomial,
but
let's
just
stick
with
the
straight
line
for
now,
so
you
have
that
straight
line
which
you
chose
essentially
at
random
and
you're,
going
to
pick
three
points
on
the
line
and
those
points
are
going
to
be.
Your
shares
all
right.
Let's
clear
everything
up
now.
AK
What
happens
is
lines
have
this
very
nice
geometric
property
that
says
that
any
two
points
on
a
line
are
enough
to
uniquely
determine
the
properties
of
your
straight
line
and
in
this
context,
that
translates
to
any
two
shares
generate
the
correct
Secret
just
check
it
out.
If
I
have
those
two
points
shares
one
and
three,
let's
assume
that
sure
two
got
lost.
AK
You
generate
the
straight
line
just
as
before,
and
lo
and
behold,
the
intersection
with
the
y-axis
is
the
secret
that
you
were
trying
to
conceal,
and
this
is
going
to
be
the
same,
regardless
of
which
two
shares
you
have
it's
independent
of
that
right.
You
have
here
to
ensure
three,
you
do
the
exact
same
thing.
You
get
the
same
secret
every
time,
so
we
got
that
nice
redundancy
property
we're
after
in
this
example-
and
this
is
kind
of
unwieldy
and
a
little
bit
hard
to
read
the
shares
are
the
following:
the
first
one.
AK
AK
Now
we
don't
like
this,
it's
hard
to
read
so
we're
going
to
use
the
bib39
dictionary
once
more
to
turn
this
into
words
like
so
and
now
that's
more
familiar.
AK
All
right,
so
this
is
what
Shamir
secretary
is
all
about,
but
I
want
you
to
notice
a
special
detail
here,
which
is
that
sorry,
my
bad
I
am
keeping
the
ID
numbers
next
to
the
shares.
They
must
be
labeled,
and
this
is
crucial
if
I
were
not
to
do
that
like
what
would
happen
if
I
misroad,
one
of
the
ID
numbers
and
I
mislabeled,
one
of
the
many
shares
that
I
have.
AK
You're
gonna
get
something
different.
You
get
the
wrong
secret
and
that's
a
problem.
This
may
not
sound
like
a
big
deal,
but
keep
in
mind
that
you
may
be
dealing
with
many
shares
at
a
time.
You
may
be
dealing
with
12
points
at
a
time
if
the
labels
get
lost,
it
can
be
a
bit
of
a
nuisance
like
solving
for
all
the
possible
permutations
and
trying
to
find
which
one
is
the
correct
one.
AK
AK
This
we
are
trying
to
circumvent
the
label
in
entirely.
Can
we
encode
the
ID
numbers
in
the
C
phrase
itself,
without
having
the
need
to
add
any
extra
words
to
the
seed
phrase?
This
would
be
nice
because
then
I
could
like
just
mix
those
seed
phrases
and
no
information
would
be
lost,
even
if
the
labeling
was
incorrect,
as
it
turns
out
there's
a
peculiarity
about
bit
39
seat
versus
standard
that
we
can
exploit
to
our
advantage
here.
AK
It
turns
out
that
not
all
the
bits
corresponding
to
the
seed
phrase
carry
independent
information.
There's
a
checksum
hidden
in
here
in
the
particular
case
of
12
Words,
which
is
what
we're
dealing
with.
It
turns
out
that
the
last
four
bits
are
not
independent.
Information
like
you
took
the
seed
phrase
from
the
initial
example,
the
one
with
a
thousand
ether.
You
turn
it
into
binary
and
these
four
numbers
they
do
not
carry
independent
information.
AK
What
they
do
carry
is
a
checksum
go
ahead
and
take
all
of
the
bits,
except
for
the
last
four
compute
shot,
256
of
that
in
binary
and
you're
going
to
get
a
hash.
The
first
four
bits
of
that
hash
are
what
you
put
in
here,
and
this
is
there
so
that,
if
you
like
miswrite
one
of
your
words,
then
like
a
wallet,
software
can
tell
you
that
you
messed
up.
AK
AK
We
have
the
this
beautiful
seed
phrase
once
again,
this
is
the
binary
encoding
of
it,
and,
let's
just
discard
this,
we
can
do
that
without
fear,
because
this
information
can
be
regenerated
whenever
we
want
now
you're
going
to
do
Shamir
secret,
sharing
the
same
like
straight
line.
Put
the
secret
on
the
y-axis
choose
a
random
line,
passing
through
it
on
the
non-checksome
bits,
so
the
the
ones
that
actually
carry
information,
and
this
time
once
you
do
that,
let's
say
that
we
get
these
shares
once
again,
this
is
hard
to
read.
AK
We
don't
like
this
format,
but
before
we
can
turn
it
into
words,
using
the
dictionary
we're
going
to
need
to
fill
in
these
gaps
right
now.
Here's
the
nice
thing.
These
caps
are
places
where
we
can
store
extra
information.
AK
For
example,
I
could
take
these
ID
numbers
and
encode
them
into
binary,
and
those
will
be
the
last
four
bits
with
ID
numbers.
I
mean
those
would
be
the
last
four
bits
of
each
of
my
shares
that
I
can
put
in
there
now.
I
turn
this
into
a
seat
phrase
once
again
like
all
of
those
into
seat
traces,
and
you
would
get
these
three
shares
notice
that
they
do
not
have
any
labels
anymore.
AK
You
don't
really
need
to
because
if
you
take
the
last
word
in
each
of
those
and
you
turn
it
into
binary
with
the
dictionary,
for
example,
popular
this
one
ends
in
zero:
zero,
zero
one,
meaning
that
this
should
be
the
first
share.
This
one
ends
in
zero:
zero
one
ten
about
the
chaos,
the
encodone
of
chaos,
meaning
that
this
has
to
be
the
second
entry
and
likewise
for
this
one.
AK
So
this
is
a
Nifty
little
trick
that
you
can
use.
If
you
want
to
get
rid
of
the
labeling
there's
other
things
you
can
do
with
that.
With
that
extra
space
for
information,
you
could
add
a
checksum
to
the
to
the
shares
themselves.
That's
something
you
could
do,
but
we're
choosing
to
do
this
because
it's
it
seems
like
a
convenient
extra
feature
that
we
can
add
to
Shimmer's
secretary.
AK
And
here's
some
advertising
on
behalf
of
net
or
mind
you
can
enter
our
repo
I
mean
our
GitHub,
never
mind,
eat
and
you'll
find
this
wrapper
research
mnemonic.
So
this
is
a
tool
that
we
built
with
extra
love
to
all
the
ethereum
community.
If
you
guys
want
to
use
Premier
secret
sharing
for
your
privacy
purposes,
for
your
thousand
eight
air
drops
or
whatnot
I,
don't
know.
If
you
guys
are
that
lucky,
then
you
can
use
this
tool
and
yeah.
So
thank
you.
AK
AF
Hi,
is
it
possible
that,
when
converting
to
shares
it
no
longer
fits
into
12
words
and
has
to
be
like
13
words
or
something
that's.
AK
A
good
question,
so
what
can
happen?
Is
we
have
four
bits
of
wiggle
room
right?
That
means
that
we
can
label
as
many
as
16
shares.
If
you
wanted
to
go
above
that,
we
would
need
extra
bits
and
you
will
need
an
extra
word.
So
we
don't
really
like
that.
We
that
that
seems
not
very
elegant.
So
what
we
do
is
we
limit
the
functionality
of
this
feature
to
if
you're
dealing
with
12
word,
seed
phrases
to
16
shares
maximum,
which
in
practice
is
a
sensible
restriction.
AK
We've
seen
that,
like
important
multistix
all
over
the
ethereum
community,
they
normally
don't
go
over
like
11
shares
or
whatnot,
but
if
you
were
to
use
like
a
24
seat
phrase,
for
example,
then
you
have
more
bits
that
you
can
use
I,
think
you
have
like
seven
or
eight
bits
for
the
encoding,
and
then
you
have
like
256
shares
that
you
can
use,
but
yeah,
that's
a
good
question
and
there's
a
there's
a
limit
on
how
many
of
these
you
can
label,
but
the
limit
is
sensible,
considering
like
the
the
real
world
use
cases.
C
Cool,
thank
you
so
much
up
next
is
the
last,
but
equally
amazing
dog
on
this
stage,
which
is
remix
rewarding
by
Andy.
AL
We
are
very
strongly
open
source
and
with
at
least
67
contributors
to
the
code
base
to
date.
So
we're
very
fortunate
in
that
and
we're
here
today
to
officially
launch
a
program
we've
designed
and
built
in
order
to
stay
engaged
with
that
growing
open
source
community
called
remix
Rewards.
AL
AL
Wrong
match
anyway,
essentially
remix
rewards
is
like
oh
yeah,
I've,
already
done
that
at
the
beginning
of
this
year
we
set
out
on
our
roadmap.
One
of
the
important
goals
was
to
consider
who
exactly
are
our
users
or
how
do
we
know
exactly
what
they're
doing
out
there?
The
initial
answer
was,
obviously
no
we
didn't
know
at
all,
so
we
started
by
using
some
design
thinking,
principles
and
tried
coming
up
with
the
user
persona,
which
we
quickly
realized,
was
kind
of
a
futile
exercise.
AL
When
we
tried
to
match
that
method
up
with
what
we
were
hearing
from
users
on
our
support
channels,
particularly
Twitter,
those
channels
displayed
a
much
wider
array
of
different
people
in
different
countries,
with
different
workflows
and
remix.
So
to
connect
more
directly
with
them,
we
started
doing
monthly,
ask
remix
anything,
calls
and
then
started
inviting
our
users
to
beta
test
new
release
is
a
remix.
AL
We'd
also
started
tracking
analytics
on
this
site
and
then
putting
all
of
this
together.
We
were
getting
the
idea
that
our
users
were
a
much
more
diverse
group
than
what
we
thought
we
had
a
handle
on.
Originally,
we
also
realize
lots
of
those
users
were
excited
about
feature
improvements
excited
about
developing
new
plugins
for
new
networks,
and
we
were
now
engaging
with
them
in
a
more
genuine
dialogue
about
these
issues.
AL
So,
following
some
success
with
the
team
at
East
Denver
developing
an
nft
song,
playlist
and
minting
dap
for
public
radio
beyond
our
team
lead
over.
There
started
building
this
program,
Rewards
program
again:
dog
food
and
remix
customizing,
an
ERC
721
contract
to
allow
minting
of
an
additional
nft
from
a
non-transferable
nft.
We
decided
to
make
these
rewards
non-transferable
both
as
a
way
to
kind
of
have
a
soul-bound
credential
for
community
members
and
to
identify
each
other
as
engaged
members.
AL
It
also
as
a
way
to
kind
of
stay
away
from
any
kind
of
Market
in
trading
them
for
money,
the
nft
kind
of
craze
for
the
look
and
feel
we
engaged
the
graphic
artist
who
had
designed
our
Remy
hedgehog
logo
over
there
on
the
left.
She
came
up
with
these
old-fashioned
Lo-Fi
framed
card
designs.
You
see
here
they
came
to
represent
our
kind
of
user
archetypes
that
one
on
the
right
is
a
Dev
connector.
That
was
our
first
nft
badge
that
came
out
at
devconnect
in
April.
AL
AL
So
if,
in
the
future,
we
can
see
a
way
to
integrating
these
payloads
with
GitHub
or
LinkedIn
or
another
third-party
cert
platform,
we
are
ready
to
do
that.
AL
Here's
the
dab
that
would
that
was
built
by
one
of
our
team
members,
Joseph
isang,
for
display
of
raw
Rewards,
again
customizing
for
our
own
needs.
We
we
did
consider
using
quixotic,
which
is
kind
of
becoming
the
open
c
for
optimism
as
an
app
for
display
and
minting.
But
at
least
for
now
our
own
build
of
this
dap
gives
us
that
better
idea
of
user
engagement
and
them
in
that
open
source
mindset.
AL
Essentially,
that's
the
story.
We
might
as
well
say
we're
officially
launching
this
program
right
now,
so
check
it
out.
If
you
get
a
chance,
there's
the
URL
up
there.
The
DAP
is
also
linked
from
our
project
website
and
obviously
we're
looking
for
as
much
feedback
and
engagement
is
possible
on
this,
so
did
any
of
us
up
after
here
or
on
Twitter
or
getter
or
Discord
they're,
all
up
there
and
lastly,
as
always,
hope
everyone's
having
fun
with
whatever
they're
building
out
there.
Thank
you.