►
From YouTube: Crosschain Security Considerations for the Degen in All of Us by Layne Haber | Devcon Bogotá
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/crosschain-security-considerations-for-the-degen-in-all-of-us/
Crosschain applications (xApps) are often considered too risky, but this viewpoint is divorced from reality. People **will** use these applications and it is our responsibility to understand the security implications. xApp developers must be able to reason about concurrency and asynchrony across two different networks, as well as understand the trust assumptions introduced by the data transport layer. By understanding this, we can allow users to engage in risky behavior in the safest way.
Speaker(s): Layne Haber
Skill level: Intermediate
Track: Security
Keywords: security,crosschain,multichain
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
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
d-gen
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.
A
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.
A
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.
A
So
if
you're
on
polygon
and
you've
withdraw
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.
A
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.
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.
A
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.
A
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.
A
So
not
only
do
you
have
to
know
everything
about
your
system,
but
you
have
to
know
everything
about
the
underlying
domains
that
that
you're,
connecting
because
the
code
that
you
write
will
not
run
the
same
on
optimism
or
arbitrum
or
polygon.
There
are
slight
differences
that
will
impact
you,
because
there's
slight
differences
that
you
may
not
understand
fully
are
going
to
be
the
ones
that
end
up
being
your
downfall.
A
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
mental
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.
A
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
a
missing
triangle,
but
you
can
also
have
low
latency
trust,
minimized
and
extensible
ridges.
Those
are
more
like
liquidity
networks
like
Atomic
transfers
would
have
that
because
you
can't
pass
General
data
through.
A
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
domain's
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.
A
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.
A
A
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.
A
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
math
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.
A
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
a
certain
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.
A
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?
A
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
it
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.
A
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
percent
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.
A
Otherwise
you
everybody
does
have
some
sort
of
bribery
prize,
so
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.
A
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.
A
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.
A
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.
What's
your
test
coverage?
Are
your
bug?
Bounties
live?
Have
you
done
war
games?
A
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.
A
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.
A
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
really.
A
The
best
way
to
do
that
is
to
add
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
percent
attack,
you
don't
really
have
a
strong
defense
against
that
for
externally
verified
Bridges.
A
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.
A
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
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.
A
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.
A
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.
A
All
of
the
projects
that
are
creating
Bridges
right
now
are
young
and
they
are
resource
constrained
and
when
you
are
creating
a
project
of
any
type
like
hacks
are
a
low
probability
high
impact
event,
and
there
are
several
other
things
that
could
kill
your
project,
so
you
are
going
to
be
forced
into
making
different
types
of
trade-offs.
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.
A
A
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.
A
And
then
you
also
have
elements
of
centralization.
That
means
like
possibility.
You
have
centralized
supporting
services
so
in
bridges.
Actually,
if
you
are
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.
A
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?
A
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?
A
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.
Now
the
other
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.
A
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?
A
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.
A
B
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
of
like
security
and
speed
like
time
to
deploy
time
for
time
to
production?
How
do
you,
how
do
you
weigh
those
things
that
connects?
How
do
you
make
the
decision
of
save
centralizing
some
aspects,
for
example,.
A
Yeah
well,
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.
A
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.
B
A
C
A
Sure
that
super
strong
super
strong
opinions
about
that
personally,
yeah
yeah
I,
think
like
you
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
main
net
test
bed:
contract
environment
where
you
can
run
these
tests
and
then
you
need
to
do
some
fire
drills,
like
red
team,
blue
team.