►
From YouTube: Battle of the Bridges: Untangling the Tradeoffs of Various Bridge Designs | 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/battle-of-the-bridges-untangling-the-tradeoffs-of-various-bridge-designs/
This panel invites 3 of the leading bridge protocols to debate the various tradeoffs that have emerged between different cross chain bridge designs, including pros and cons, and security considerations. Panelists include the founders of Across (Hart Lambur), Hop (Chris Whinfrey), Succinct (Uma Roy), and will be moderated by Tarun Chitra (Gauntlet).
Speaker(s): Tarun Chitra, Hart Lambur, Chris Whinfrey, Uma Roy
Track: Security
Keywords: bridges,cross-chain
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
B
Thank
you
for
the
far
too
kind
intro
and
in
fact,
because
you've
said
so
many
nice
things
about
me.
That's
how
I
know
you're
full
of
but
it's
fine
anyway,
so
yeah
so
I
guess
as
a
first.
You
know,
let's
start
with
all
the
big
intros
is
you
know
we
have
you
three
I
know
two
of
you
quite
well
Chris.
Unfortunately,
I
don't
quite
know
you,
so
that
means
I'm
going
to
pick
on
you
to
start.
Give
me
a
30-second
intro
of
who
are
you?
What
do
you
do?
C
A
C
B
A
D
Hi
I'm
Uma
I'm,
the
co-founder
of
succinct,
Labs,
we're
a
newer
project
company
that
started
just
this
past
summer
and
we're
working
on
a
proof-based
bridge.
So
also
we
can
talk
about
the
design.
People
also
call
this
a
ZK
Bridge,
there's
nothing
like
zero
knowledge
about
it.
So
I
like
to
call
it
a
proof-based
bridge
and
yeah.
We
can
just
talk
about
how
all
the
snarks
work
and
how
yeah
our
bridge
is
going
to
work.
B
Cool
so
I
guess
to
start
bridges
are
kind
of
a
fraught
area
in
a
lot
of
ways,
not
just
because
of
the
hacks,
but
I
mean
like
you
know,
even
definitionally
people
are
like,
oh,
like
that's
a
bridge
or
that's
not
a
bridge
or
whatever,
and
there's
a
bunch
of
categories
of
bridges
right.
So
first
things.
First
I
guess
can
one
of
you,
whoever
is
feeling
the
spiciest,
or
at
least
spicy,
depending
on
your
day,
describe
to
me
like
what
are
the
categories
for
like
what?
B
What
like
there's
like
an
ecosystem
of
different
types
of
bridges,
you
know
there's
like
succinct
bridges
that
use
like
ZK
the
power
of
ZK
trademark.
There
are,
like
kind
of
you,
know
a
bunch
of
other
designs
so
well,
actually,
maybe
before
we
even
yeah.
So
let's,
let's
set
the
definitions.
First.
Can
anyone
give
me
like
how
these
Bridges
separate
into
like
their
respective
categories,
so
to
speak?.
A
A
B
C
You
know
we
actually
rely
on
these
wrapped
asset
Bridges
to
exist,
so
every
single
roll-up
has
a
wrapped
asset
bridge
and-
and
you
you
know,
you
deposit
into
the
layer.
One
contract
and
a
representation
of
that
deposit
is
minted
on
Layer
Two,
so
with
Roll-Ups
you're
able
to
kind
of
secure
the
whole
wrapped
asset
Bridge
with
a
smart
contract.
But
where
we've
seen
things
go
wrong
is
when
you
have
a
racked
asset
bridge.
C
That
is
a
multi-sig,
because
racked
acid
Bridges
need
to
hold
a
lot
more
tvl
than
liquidity
Bridges,
because
they're
not
just
holding
enough
liquidity
to
kind
of
facilitate
cross
training,
transfers,
they're,
actually
holding
all
of
the
liquidity
of
that
cross-chain
asset,
and
so
what
liquidity
Bridges
do?
Is
we
basically
bridge
between
assets
that
are
produced
by
wrapped
acid
Bridges
I'll.
A
But
I
would
argue,
that's
not
exactly
the
same
type
of
it's
it's
different,
because
it's
adopting
the
same
security
parameters
as
the
roll-up
itself,
and
so,
if
you
trust
the
roll
up,
you're,
fundamentally
trusting
this
supposed
wrapped
asset.
So
I
almost
refer
to
that
as
like
the
native
version
of
that
asset
on
the
roll
up,
the
type
of
wrapped
asset
bridge
that
I
think
Chris
is
on
and
I
totally
agree
is
the
one
where
you
literally
do
just
like.
A
Take
the
wrapped
asset,
lock,
an
ethereum
and
then
there's
like
an
oracle
or
like
a
different
security
method.
That's
potentially
super
insecure.
That's
minting
your
representation
that
on
your
destination
chain
and
then
for
the
user
of
that
asset
on
that
destination
chain.
That
user
has
Perpetual
risk
to
the
security
of
that
Oracle
in
perpetuity
and
if
that
ever
breaks
that
user,
that
just
thought
they
held
this
valid
asset
and
left
with
a
donut
and
those
are
the
designs
that
I
think
are
really
dangerous
and
not
cool.
So
sorry,.
D
B
Cool
okay,
so
I
don't
have
I,
don't
think
I
have
any
additional
questions
about
the
specifics
of
liquidity.
Bridges
I
will
have
additional
questions
which
we'll
start
right
now
about.
What
is
your
liquidity
Bridge
like?
How
do
you
describe
it?
What
is
the
architecture?
How
does
one
construct
it
like?
What
is
this
thing
sure.
C
So
with
hop,
we
we've
kind
of
come
up
with
this
like
Hub
and
spoke
model
where
we
use
ethereum
to
pass
messages
between
different
networks.
So
these
are
layer,
twos
or
side
chains
like
polygon
or
gnosis
chain,
and
so
we
leverage
each
of
the
Native
message
Bridges.
So
each
of
these
kind
of
Layer,
Two
networks
or
side
chains
has
a
message
Bridge
with
ethereum,
where
we
can
send
messages
and
what
we
do
is
we
actually
bundle
many
messages
at
the
source
chain
and
then
we'll
miraculize
those
on
chain.
C
After
you
know,
many
messages
have
been
sent.
We
can
propagate
this
message
or
this
Merkle
root
through
layer,
1
ethereum
to
the
destination,
and
this
is
how
we
can
do
scalable,
but
but
very
slow
messaging,
and
then
we
add
a
liquidity
layer.
On
top
of
that,
where
we
have
liquidity
providers
that
you
know
kind
of
front
liquidity,
when
a
user
makes
a
bridge
transfer
and
then,
as
those
transfers
happen,
many
of
them
get
bundled
up.
B
A
Tell
us
about
so
yeah
there's,
there's
a
lot
of
similarities
and
then
some
important
differences
so
across
actually
only
supports
chains
that
have
a
native
asset
Bridge
with
ethereum.
So
what
a
cross
does
is
we
actually
only
have
a
single
liquidity
pool
of
the
protocol?
The
way
to
think
about
it
is
the
protocol
is
effectively
the
settlement
layer,
so
you
have
a
single
liquidity
pool
and
the
protocol
will
send
assets
from
that
liquidity
pool
to
various
spoke
destinations
that
can
be
slow.
That
can
be
painful.
That
can
actually
be
quite
costly.
A
So
what
across
does
is
we
have
a
a
third-party
actor?
We
call
a
relayer,
and
so,
if
Uma
wants
to
move
assets
from
one
chain
to
another,
this
relay
will
effectively
front
them.
Capital,
they'll,
they'll
front
they'll,
send
the
assets
immediately
so
very
quickly
to
them
on
the
destination
chain
and
then
it'll
request
to
be
repaid
optimistically
from
the
liquidity
Network
in
the
protocol,
and
so
the
advantages
of
this
is
we,
since
the
protocol
is
kind
of
continuously
rebalancing
its
liquidity
between
its
hubs
and
spokes.
A
We
like
to
think
of
this
as
a
very
Capital
efficient
design,
where
we're
trying
to
use
as
little
Capital
as
possible
to
do
as
much
volume
as
we
can
and
kanada
uma's
earlier
point.
The
sort
of
thesis
here
is
less
tvl
better
per
unit
of
volume,
so
the
more
Capital
efficient
you
can
have
not
only
are
like
fees
lower.
A
A
Risk
like
there's
different:
it's
not
really
like
Market
risk.
They
don't
have
risk
to
like
the
price
of
ethereum,
going
up
or
down
type
thing.
If
they're
sorry,
I
should
be
clear
if
you're
denominating
your
if
you're
holding
that
ethereum
and
you're
not
planning
on
selling
it.
If
you
think
of
it
as
like
stuff,
you
own
you're,
not
taking
risk
you're,
making
a
loan
in
this
in
this
asset.
A
Yes,
you
charge
a
small
fee,
okay,
so
it's
basically
like
you
charge
like
a
two-bit
fee
on
this.
This
loan
two
bips
over
two
hours,
annualizes
to
a
very
healthy
return
and
again
there's
ways
where
this
could
be
a
more
competitive.
It
could
be
auctions
or
whatever
else.
The
other
thing
that's
kind
of
interesting
about
our
relayer
design
is
the
relayers
they
get
to
choose
where
they
get
paid
back
so,
for
example,
a
relayer.
If
Uma
was
moving
assets
from
arbitrary
optimism,
the
realer
could
ask
it
paid
back
on
polygon.
A
B
D
I
think
our
Bridge
or
what's
the
Sanctus
building,
is
not
a
liquidity
layer.
It's
not
even
necessarily
like
a
token
or
asset
bridge
I.
Think
we're
starting
off
by
really
focusing
on
the
arbitrary
message
passing
part.
So
I
think
that's
like
a
big
difference.
The
high
level
design
is
basically
similar
to
IBC
how
you
have
like
a
light
client
running
in
the
execution
layer
of
a
Target
chain
for
a
source
chain.
D
Once
you
have
that
light
client
for
a
source
chain
running
in
the
execution
layer
of
the
target
chain,
then
you
have
access
to
the
source
chain,
State
similar
to
how
you
guys,
I
guess,
use
like
your
the
you
propagate
the
Merkel
route,
to
send
a
message
here.
If
you
have
like
ethereum's
state
route
on
gnosis
chain,
then
you
can
prove
things
about.
Like
oh
stuff
happened
on
ethereum,
so
you
could
have
a
arbitrary
message.
D
Bridge
contract
on
ethereum
that
users
send
contract,
calls
to,
and
then
a
relayer
would
send
a
proof
on
notices
chain,
for
example,
that,
like
oh,
this
message
was
sent
on
ethereum
and
now
you
should
like
execute
this
corresponding
message
on
gnosis,
and
so
when
you
have
arbitrary
message,
passing
or
arbitrary
data
passing,
of
course,
on
top
of
that,
you
can
build
a
token
Bridge.
You
can
build
a
liquidity
layer.
You
can
build
all
this
stuff,
but
yeah
I
think
our
main
focus
is
basically
on
making
this,
like
trust,
minimized,
cross-chain
communication
layer
to.
B
Start
on
the
topic
of
trust
minimization,
which
I
suspect
you
have
at
least
some
opinions
of
maybe
unclear.
So
first
things:
first,
how
does
trust
affect
kind
of
the
safety
of
a
bridge,
A
and
B?
You
know
kind
of
the
maybe
like
higher.
Maybe
mid-width
question
is:
can
you
make
a
safe
Bridge
right
like?
Can
you
like,
let's
Bridges,
seem
fairly
complicated
in
some
way
or
another?
You
know
it's
like
a
lot
of
moving
Parts,
potentially
you're
dealing
with
like
many
distributed
systems
Can.
B
D
I
think
the
trust
assumptions
are
really
important.
So
currently,
most
bridges
have
basically
like
a
multi-sig
or
a
multi-sig
in
some
form
trust
assumption,
and
so
that's
really
bad
because
of
course,
for
something
like
ethereum,
where
you
have
many
many
validators
and
a
ton
of
Economic
Security,
your
multi-sig
is
never
going
to
have
the
same
amount
of
security.
D
So
I
think
the
trust
assumptions
are
really
important
and
if
we
can
basically
have
a
bridge
out
of
ethereum
that
has
ethereum's
level
of
security
securing
it
which,
in
a
light
client,
you
can
have
if
you're
verifying
ethereum's
consensus
in
the
execution
layer
of
another
chain,
you
can
okay.
So
it's
actually
a
little
more
nuanced
you're,
not
getting
all
the
way
there,
but
you're
getting
significantly
more
there
than
having
a
multi-sig
I.
Think
that's
a
huge
Improvement
in
terms
of
the
trust
model
of
a
bridge
and
I.
Think
that's
really
important.
I!
D
Think,
of
course,
with
a
lot
of
bridge
hacks.
There's
some
Bridge
hacks
that
have
been
based
on
the
trust
model
so,
like
there's,
been
some
Bridge
hacks
with
a
multi-sig
where
they
actually
compromise
like
the
multi-stick,
signer
keys,
and
so
that's
an
illustration
of.
Oh,
the
multi-sig
is
very
insecure.
There's
a
lot
of
other
Bridge
hacks,
which
are
just
smart
contract
hacks
or
like
smart
contract,
bugs
those.
Of
course
it
doesn't
matter
what
the
trust
model
was
like.
D
B
B
A
A
A
Right
but
you
audit
your
code
formally
verifying
your
code.
That
seems
like
a
great
idea
right,
but
formal
verification.
It
has
its
own
trade-offs,
I.
Think
of
understanding
that
and
writing
the
rule
set.
Actually
Chris
might
have
opinions
on
that
too.
Then
bugging
money
program
right
and
then
you
also
just
like
you.
A
You
last,
like
part
of
the
reason
why
you
gotta
like
time
the
the
more
surf
the
longer
you
survive.
I,
truly
believe
the
more
credible
your
product
is
because
it
is
very
antagonistic
environment
out
there,
and
so
just
surviving
I
think
is
is
is
increasingly
it
just
means
you're
you're,
more
the
longer
you
survive,
the
more
likely
you
are
to
survive.
In
my
opinion,.
D
For
example,
I
think
if
you
look
at
the
maker,
smart
contracts
or
the
compound
smart
contracts
compared
to
a
bridge
smart
contract,
it's
much
more
complicated,
there's
much
more
moving
pieces
and
people
have
seemed
you
know,
of
course
those
things
have
bugs
too,
but
like
people
have
seemed
to
figure
out
ways
to
make
these
smart
contracts
in
ways
that
are,
you
know,
bug
minimized
or
like
not
catastrophic,
and
so
I
don't
think
they're
theoretically
seems
like
oh,
it
should
be
impossible
to
make
a
secure
bridge
I.
Actually
it's
maybe
even
a
good
question.
D
C
I
completely
agree,
I
I
think
those
are
you
know
both
great
answers
like
we
need
to
build
up
our
lindiness
to
you
know,
as
as
Bridges
exist
for
longer
and
longer
without
being
hacked
the
you
know
the
more.
We
can
trust
them
to
not
be
hacked
in
the
future,
but
you
know
one
thing:
I
wanted
to
really
hammer
on
which
you
touched
on
it's
if
you're
using
a
trusted,
Bridge
you're,
not
just
trusting
whoever
these
parties
are,
you
know
it
might
be.
C
You
know
sequoia
or
a16z,
that's
holding
this
key,
but
you
know
what
we've
seen
is
that
over
a
billion
dollars
has
been
hacked
from
multi-sig
Bridges,
and
it's
not
that
these
parties
are
just
like
turning
malicious
and
running
away
with
the
money.
You're
trusting
these
people
to
have
world-class
security.
This
is
not
just
you
know,
average
everyday
hackers
that
are
that
are
going
after
these
Bridges.
This
is
you
know,
so
it's
nation
state
level
actors.
You
know
like
North,
Korea's,
Lazarus
group.
They
are
trying
to
insert
employees
into
your
company.
C
A
Yeah,
like
I,
mean
again,
let's
emphasize
the
trustlessness
and
permissionlessness
are
like
they're,
not
really
features
they're
requirements.
Ultimately
and
again.
If,
if
you
just
want
to
trust
somebody,
then
like
you,
don't
need
a
bridge,
you
just
use
binance
as
your
Bridge
right
and
like
fine,
my
favorite
bridges,
coinbase.
B
A
D
Know
yeah
I
think,
as
the
regulatory
landscape
gets
more
and
more
like
strict
having
the
multi-sig
is
going
to
really
be
tough
just
from
like
a
regulatory
perspective
and
I.
Think
that's.
Why,
like
the
snark
approach
or
this
proof-based
approach,
where
it's
like
for
these
like
clients,
you
know,
theoretically,
anyone
can
generate
the
proof.
Anyone
can
send
the
proof
to
the
smart
contract.
On
the
other
side,
anyone
can
relay
a
message
and
it's
like
truly
uncensorable.
It's
like
we're
going
to
be
very,
very
important.
Remember.
A
D
I
think
trustless
is
like
a
really
strong
term
and
a
lot
of
people
have
a
lot
of
feelings
about
it.
So
yeah
we
try
to
be
aware
of
that.
I
think
it's
trust
minimized
because
ultimately,
you're
still
trusting
the
consensus
of
the
other
chains.
So,
for
example,
if
you
know
okay,
ethereum
has
really
good
security,
Economic
Security
but
say
I'm
bridging
from
another
chain
back
into
ethereum
and
say
that
chain
only
has
you
know,
10
million
dollars
of
Economic,
Security
I.
Think
it's!
B
Fair
enough
so
essentially
kind
of
the
way
I
can
summarize
this
latter
part
of
the
panel
is
that,
like
smart
contract
security,
anything
that's
unsafe
is
just
cope
right,
like
you
are
like
if
you're
just
you're,
just
not
you're,
just
doing
it
wrong.
If
you
just
like
have
I
mean
right,
like
you
were
mentioning
right,
maker
Dao
is
like
this
massive
set
of
contracts
and,
like
I,
don't
know,
has
it
been
hacked
as
far
as
I
know?
No,
like
so
I
mean.
What
is
your
perspective
on
this
like?
How
do
you
make
smart
contracts
secure?
C
No,
so
actually
so,
the
most
num
in
terms
of
number
of
bridge
hacks
has
been
just
regular:
smart
contract,
vulnerabilities
and
yeah.
There
is
no
reason
for
these
vulnerabilities
to
be
Bridge
specific.
You
know
a
lot
of
them
are
signature
based
or
some
of
them
are
just
you
know,
regular
smart
contract
bugs,
and
so
when,
when
we
design
smart
contracts,
we
design
them
in
a
way
that
makes
it
easier
easy
for
an
auditor
to
look
at
the
code
and
verify
our
security
variants.
So
you
know
these
security
and
variants.
C
Are
you
know
if,
if
a
token
kind
of
like
starts
a
transfer
here,
is
it
going
to
be
completed
here?
Can
you
know
multiple
completions
happen
at
the
destination?
Is
there
some
other
way
for
for
someone
to
kind
of
like
extract
value
from
the
bridge?
And
so,
if
we
can,
you
know
basically
make
it
as
simple
as
possible
to
to
verify
those
things
the
the
easier
it
is
for
Auditors
to
kind
of
catch
any
bugs
that
might
show
up
essentially.
C
B
And
I
guess
as
a
follow-up
question,
what
does
it
feel
like?
Every
bridge
has
been
hacked
and
not
like
every
smart
D5
contract
has
been
hacked.
Is
it
just
like
a
bridge
specific
thing?
Is
it
just
like
everyone
decides
to
hop
on
a
bridge
and
be
like?
Oh,
this
is
cool
like
we're.
Just
gonna
like
put
a
lot
of
money
in
here
like
what
what
is
it
like?
It
feels
that
way,
because.
C
It's
kind
of
true
and
honestly
I
think
it's
because
it's
a
new
market
and
it's
a
it's
a
you
know,
there's
a
big
opportunity
and
so
a
lot
of
people
are
kind
of
just
jumping
in
a
little
too
fast.
Auditors
were
very,
very
constrained
during
the
bull
market,
so
it
was
like
really
hard
and
really
expensive
to
book,
a
good
auditor,
and
but
people
still
wanted
to
be.
You
know
in
that
market
early
and-
and
so
we
saw
a
lot
of
them,
get
hacked.
A
A
B
Interesting,
okay,
and
so
with
that
you
know
it
kind
of
like
we're
taking
a
little
bit
of
a
digression
here,
but
I'm
curious.
So
do
you
think
the
bridge
space
is
like
fundamentally
a
Cooperative
space,
or
do
you
think
it's
very
much
a
winner
takes
all
space
in
your
case
and
what
would
the
winner
look
like?
I
mean
I?
B
Guess
if
you
knew
you
would
already
be
building
it,
but
or
maybe
you
are
building
it
but
like
fundamentally,
it
feels
like
to
me,
but
you
know,
a
bunch
of
people
are
building
bridges
right
now,
but
really,
like
kind
of
you
know,
if
you
build
a
good
Bridge,
there's
the
best
bridge
and
that's
kind
of
it
like
it
feels
like
there's
like
a
metric
by
which
we
can
measure
Bridges
and
be
like
this
is
the
best
damn
thing
possible.
Anything
else
sucks
we're
just
going
to
use
that.
A
Wait
you
I,
don't
know
that
there
is
a
single
metric.
You
can
look
at
bridges
on
like
let's
talk
about
acid
bridges
for
a
second
here
where
you
want
like
there,
you
want
three
things
you
want
to
be
fast,
you
want
it
to
be
cheap
and
you
want
it
to
be
secure
and
so
I
want.
Those
three
things
give
me
Max
of
all
of
those
right
sure
and
so
I
I
think
that
it's
not
necessarily
clear
that
that's
going
to,
and
maybe
you
want
permissionlessness
too
I'd-
add
that
in
there
maybe
that's
in
security.
A
So,
like
look
I
think
on
the
asset,
bridging
it's
going
to
be
very
price
competitive
asset
Bridging.
The
the
kind
of
the
model
here
is
fees.
How
much
fees
are
you
taking
well
maintaining
a
minimum
level
of
security
and
that
minimum
level
of
security
should
be
like
really
high,
because
you
find
language,
I,
think
it's
okay,
yeah
trustless
and
all
that
yeah
thanks,
we're
all
adults
here,
but
so
I
I
think
that's
that's
kind
of
interesting
like
and
I
think
Chris.
A
We
can
talk
about
this
like
acid
Bridges,
it
is
going
to
be
very
competitive.
It's
great
for
the
consumer
by
the
way
right,
but
then
I
think
the
other
thing
we
can
go
into
is
talking
about.
Like
data
Bridges
I
find
it
really
interesting
how
you
even
charge
for
that
or
like
what
the
fee
model
should
be
and
I
also
don't
think
that's
at
all
figured
out
yet
either,
but
maybe
go
yeah.
C
C
You're
only
exposed
to
a
bridge
for
for
the
brief
period
that
you're
crossing
the
bridge
and
then
you're
you're
out,
and
so
you
know
in
terms
of
security,
it's
really
or
in
terms
of
cost.
You
know
it.
It
comes
down
to
like
how
secure
you
are
and
how
much
you're
going
to
have
to
pay
for
liquidity
and
the
more
secure
you
are.
The
less
you'll
have
to
pay
for
your
security
and
the
cheaper.
It
is
going
to
be
for
end
users,
but
end
users.
C
A
D
Yeah
I
think
for
users
like
end
user
token,
Bridges
have
slightly
different
desired
properties
than,
for
example,
a
data
Bridge.
That's
maybe
transmitting
like
governance
results
or,
like
other
actions
on
you,
know,
ethereum
broadcasts
out,
or
vice
versa,
so
I
actually
don't
think
it
is
like
one
number
to
optimize
that
function.
That
depends
on
like
who
your
user
is
like.
If
your
user
is
a
consumer
they're
going
to
care
about
different
things
versus
like
a
dow
versus
you.
A
A
All
thing,
I,
don't
actually
think
this
is
a
winner
takes
all
Market
on
the
asset
side.
I
think
that
being
able
to
do
a
low
volume
thing
with
minimal
tvl,
like
lots
of
capital
efficiency,
I
feel
like
that
will
be
competitive,
maybe
not
again,
Winner
Takes
all
and
then
on
the
data
side.
Again,
I
I
think
some
of
the
ZK
stuff
that
Emma's
working
on
gets
more
and
more
compelling
and
interesting,
but
I'm
also
I
don't
know.
Do
you
think
there's
been
a
winner?
Take
all
on
the
data
side.
E
D
D
C
So
you
know
we'll
probably
see
you
know
bridges
that
are
kind
of
further
down
that
power
lot,
that
they'll
probably
attack
the
longer
tail
assets,
the
longer
tail
networks
where
they
can
gain
market
share
and
and
the
the
bridges
that
are
kind
of
at
the
top
they're
going
to
be
focused
more
on
security
and
and
making
sure
that
their
LPS
don't
need
to
be
paid
a
ton.
So.
B
So
this
is.
This
is
where
this
is
where
the
question
comes
in,
which
is
you
know
in
some
sense
right,
if
you
have
like
the
maximally
secure
Bridge
like
it's
very
likely
that
it's
also
the
most
economically
efficient
Bridge
and
if
not
I
mean
like
maybe
not
is
it?
Is
that
the
case
like
do
you
think
that
there
could
be
like
you
could
like
somehow
lose
security,
but
still
have
people
not
pay
very
much
for,
like
the
privilege
of,
like
you,
know,
bridging
their
assets?
Yes,.
C
B
Feat:
yeah,
so
I'm,
gonna
I'm
gonna
make
the
simplifying
assumption
here
that
gas
costs
are.
Are
you
know,
with
magical
scaling
results
going
to
zero?
So
let's
pretend
on
our
magical
fairy
world
at
scaling,
as
we've
seen
like
70
talks
on,
are
all
perfect
and
beautiful
and
we
get
like
approximately
zero
or
negligible
costs.
C
You
know
both
both
across
and
hop,
have
both
active
liquidity
and
passive
liquidity,
there's
different
challenge
periods,
so
that
gives
you
know
different
trade-offs
between
you
know
what
these
different
liquidity
providers
are
are
kind
of
taking
on
and
then
yeah
there's
also,
you
know
different.
Just
different
models
in
terms
of
you
know
how
things
are
bridged,
so
you
know
with
hop.
You
know
you
can
kind
of
think
we
kind
of
think
of
capital
efficiency
in
like
three
buckets.
C
B
C
And
and
so,
and
so
that's
partially
the
amms,
but
also
partially,
you
know,
arbitragers
and
AMS
are
really
that's
where
they're
taking
on
the
seven
day
of
the
net
flow
and
then
the
amms
themselves,
that
kind
of
scales
to
transfer
size
but
not
transfer
volume.
So
you
know
we
could
have
a
bridge
that
that
has
two
amms
that
have
10
million
tvl
each
and
you
know
that's
going
to
be
able
to
support
pretty
large
transfers
very
efficiently,
but
that
can
scale
up
to
you
know
virtually
any
volume.
B
So
I
guess
for
just
for
a
little
bit
more
context.
So
here
the
automated
Market
maker
is
acting
as
a
way
of
so,
if
I,
let's
say
I
I,
don't
know,
I
have
eth
and
I
want
to
get
like
whatever
wbtc
on
some
Layer
Two
I
can,
instead
of
kind
of
bridging
eth
and
then
swapping
it.
I
can
just
directly
kind
of
like
Bridge
swap
in.
Is
that
correct
or
yeah?
Okay,
so
because
I'm
still
on
unclear,
also
I
guess
before
we
kind
of
get
to
that
for
context.
B
We're
talking
about
so
there's
two
layers
here
that
we
have
right.
One
of
them
is
like
the
data
layer
which
is
kind
of
what
we
were
talking
about
previously
and
what
security
models
we
have
and
there's
kind
of
like
the
economic
layer
where
we're
talking
about
economic
efficiency.
That
kind
of
is
built
on
top
of
like
a
messaging
layer
that
you
can
trust
right
and
I
want
to
make
keep
these
two
things
separate.
B
So,
let's,
while
we're
on
that
specific
topic
afterwards,
we'll
get
to
the
messaging
part
which
I
think
Uma
is,
has
some
other
spicy
takes
on,
but
okay,
so
but
anyway,
so
sorry
describe
this
amm
design
or
like
what?
What
is
the
point
of
this
automated
Market
maker,
I?
Guess
at
the
end
of
the
day,
sure.
C
So
so
the
the
main
purpose
is
actually
to
one
kind
of
price
liquidity
flows
between
different
networks,
and
then
it
also,
you
know,
there's
no
way
if
you're
just
using
the
canonical
assets
to
to
not
take
on
that
that
full
seven
day
lock
up
for
the
the
total
flow
of
of
assets,
and
so
because
we
have,
we
basically
have
this
intermediary
accounting
assets.
So
it's.
B
C
A
Yeah
the
thing
I'm
just
going
to
add
just
maybe
zoom
out
a
little
bit
like
our
take
across
this
take-
is
that
there
is.
This
is
a
financial
engineering
problem
like
if
you
solve
the
data
and
solve
the
data
message,
you
have
a
financial
engineering
problem
and
I
think
the
more
Innovative
you
can
be
with
your
financial
engineering,
the
more
Capital
efficient.
You
can
be
right,
and
so
you
know
again
hopping
across
share
a
lot
of
philosophies.
The
the
one
thing
that
we've
done
that
is
quite
different.
A
Is
we
don't
have
these
amms
at
all?
Instead,
we
are
actually
just
having
this
single,
unified
liquidity
pool
and
we're
using
the
native
Bridges
to
kind
of
rebalance
assets
between
this
Hub
and
spoke
model,
and,
if
I'm,
going
to
like
shill
our
product
a
little
bit
the
one.
The
one
thing
that
I
kind
of
like
about
this
is
I,
think
that
that
liquidity
model
allows
us
to
be
a
bit
more
Capital
efficient
than
having
amm
pools
that
have
to
be
kind
of
rebalanced
off
chain.
A
C
So
so,
like
I
said
the
the
amms,
it's
only
based
on
transfer
size,
they
just
need
to
scale
the
transfer
size,
not
transfer
volume.
So
even
you
know
if,
if
we
were
to
have
just
like
2
million
dollars
in
each
amm,
you
know
we
could
support.
You
know
unlimited
volume.
If,
as
long
as
you
know,
the
transfer
sizes
are
below
that
threshold,
then
arbitrages
are
coming
in
and
and
are
being
that
out
and.
B
C
A
Yeah-
and
it's
like
this
Concepts
again
like
call
it
like
basic
basic
Financial
engineering,
Concepts
or
like
Market,
making
Concepts
is,
if
you
can
cross
flow
like
if
you
got
a
million
dollars
going
this
way,
and
you
had
a
million
going
so
I
was
going
the
other
way,
it's
beautiful,
and
not
only
that,
but
it
means
you
have
like
really
low
costs.
You
don't
have
to
rebalance
things.
Just
did
it
all
works
out
beautifully
and
so
again,
I
think
a
lot
of
the
financial
engineering
is,
how
can
you
get?
A
B
To
it
so
so
next
up
is,
you
know
fine,
so,
let's
go
back
so
when
let's
we've
taken
this
first
part
right,
let's
like
zoom
out
and
go
to
the
second
part,
which
is
honestly
what
underpins
the
entire
Financial
infrastructure.
You
guys
are
talking
about,
and
it
is
okay.
So
now
I
ask
you
the
question
of.
Do
you
think
that
data
Bridges
will
themselves
all
kind
of
monopol
go
into
like
one
single
data
Bridge
right
like?
Why
not
you
know
kind
of?
Why
doesn't
this
become
finite,
like
just
like
standard
infrastructure?
B
That's
open
source,
that's
just
like
classic
normal.
Everyone
uses
it.
How
does
one
even
monetize
this
thing,
you
know,
for
example,
IBC
works,
pretty
damn
great
right
and
like
the
idea
would
be
IBC
for
like
ethereum
at
L
would
be
very
cool
and
obviously
that's
kind
of
what
you're
working
on.
But
how
does
one
monetize
that
I
mean
IBC
is
just
I
just
implement
the
Ping
and.
D
You
know
something
further
down.
The
line
in
my
opinion,
wallets
have
a
lot
of
other
things.
They
need
to
do
before
that
issue,
but
yeah
down
the
line,
I
think
the
assisting
light
clients
are
important
for
things
even
Beyond,
Bridges,
I
think
yeah.
That
being
said,
so
I
think
we
want
to
build
this
in
a
very
public
goods
oriented
way,
but
I
think
you
know
just
because
something's
a
public
good
doesn't
mean
that
oh,
it
has
to
make
no
money
like,
for
example,
operating
these
succinct,
like
clients
is
really
hard.
D
So
you
know
and
believe
me,
like
I've,
had
to
write
the
infrastructure
to
you,
know,
watch
one
chain
generate
the
ZK
proofs
and
then
set
up
the
infrastructure
to
Ping
a
bunch
of
different
like
clients
on
a
bunch
of
different
chains,
and
this
is
not
infrastructure
that
you
know
it
in
a
timely
manner
that
you
know
people
are
going
to
want
to
run
themselves.
Like
probably
there's
going
to
be
an
operator.
F
D
D
That
being
said,
we're
not
going
to
always
be
like
our
own
operator
like
we
don't
want
to
be
the
only
operator
for
like
censorship,
resistance,
and
so
it's
important
that
anyone
can
actually
run
the
operator
themselves
and
yeah
I.
Think
there's
like
some
interesting
things
you
can
like
do
around
that
in
the
future.
Is.
A
D
D
That's
like
yes,
my
like
client
got
updated
things
like
that
and
then
in
the
future,
I
think
a
lot
of
the
ZK
EVMS
have
been
thinking
about
really
similar
problems
where
they
really
need
proofs
to
be
generated,
but
they
don't
want
a
centralized,
prover
and
so
they're
going
to
have
like
a
decentralized
prover
Network
like
that's
separate
from
their
sequencer
and
I.
Think.
B
I
guess
you
know
kind
of
more
generally,
like
let's
say
I
want
to
prove
something
that
happens
only
once
every
once
in
a
while
right,
like
what
incentivizes
me
from
like
paying.
You
know
this,
like
big
pool.
Let's
feel
feels
like
what
a
lot
of
things
like
how
a
lot
of
things
work
right
like
we,
you
know
kind
of
only
Bridge,
or
only
like,
send
data
across
kind
of
chains
like
very
fairly
infrequently
right.
B
So
is
the
assumption
that
there's
going
to
be
like
a
large
enough
volume
that,
like
people
are,
you
know
kind
of
incentivized
to
always
run
these
things,
or
do
we
kind
of
expect
every
individual
user
to
just
like
provide
their
own
proofs
as
needed?
I,
don't
know
how
large
these
proofs,
even
are
I
mean.
How
long
does
it
take
like.
D
D
D
D
But
trusting
me
I'm
just
generating
the
proof
for
you,
but
the
chain
is
verifying
the
proof,
so
there's
no
trust
assumption
if
someone
else
is
generating
the
proof.
It's
just
a
sense
and
the
important
thing
for
censorship
resistance
is
that
you
could
generate
the
proof
like
you
could
spend
20
minutes
and
spin
up
an
AWS
machine
and
generate
the
proof
of
yourself
and
send
it
to
the
light
client
you're
generally
not
going
to
do
that
and
you're
probably
willing
to
pay
for
the
convenience
of
someone
else
doing
it.
B
F
Hey,
yes,
I
have
a
question
for
Uma.
First,
one
is
like
what
is
the
time
gap
for
you
like
to
propagate
the
blocks
like
like
from
my
understanding
like
it's
working,
similar
to
like
Rainbow
Bridge,
but
like
with
the
case
so
like
you
should
have
like
some
like
gaps
like
you,
cannot
propagate
like
every
hypnosis
chain
block
to
ethereum
and
like
basically
like
it
to
any
chain
to
if
you're,
you
cannot
propagate
like
every
block
and,
like
the
second
question
like
how
much
does
it
cost
to
like?
D
Yeah,
so
the
question
kind
of
was:
how
long
does
it
take
to
propagate
a
block
and
presumably
you're,
not
propagating
every
block?
Yeah,
that's
right.
So
for
us,
like
the
block
propagation
time
is
first,
we
need
to
wait
for
ethereum
to
finalize,
so
that
generally
takes
an
expectation
around
two
epochs
which
is
like
around
12
minutes
and
then
on
top
of
that
we
have
our
proof
generation
time
for
the
particular
block.
D
D
With
proof
of
stake.
You
don't
need
to
propagate
every
block,
so
in
proof
of
work
you
actually
do
because
the
longest
chain
is
this
like
sequential
thing,
so
you
need
to
verify
every
single
block
to
verify
the
chain
is
the
longest,
but
for
proof
of
stake.
As
long
as
the
validator
set
stays
the
same,
you
can
just
send
an
arbitrary
block
as
long
as
you
have
the
same
validator
set
and
so
for
us.
We
like
send
a
block,
you
know.
Currently
we
do
it
every
10
minutes
or
something
like
that.
D
Just
you
know,
and
so
there's
like
an
extra
10
minute
delay
on
your
Bridge,
basically,
and
so
there's
like
a
trade-off
between
how
often
you
want
to
propagate
blocks
and
the
gas
costs
you're
willing
to
tolerate.
But
if
you
have
like
a
huge
transfer
for
example,
that
you
want
to
do
right
now,
you
could
like
send
the
block
right
now.
A
D
D
What
I
can
do
we
don't
do
this
right
now,
but
what
we're
working
on
is,
if
you've
approved
a
consensus
for
three
different
chains,
you
can
actually
recursively
prove
them
in
one
snark,
and
so
what
happens?
Is
you're
amortizing
the
gas
costs
across
all
your
partners
that
you're
bridging
across,
and
so
that's
really
nice,
because
with
recursive
snarks
you
can
stuff
basically
and
unbalted
amount
of
computation
into
180k
gas
and
so
I
think
in
the
future.
When
everyone
starts
using
this,
then
actually
it
becomes
gas
efficient
enough.
G
You're
talking
about
the
proofs
proof
generalizer,
for
example,
for
ethereum
to
to
another,
but
it's
I
mean
it's
quite
complicated
task
right
to
generate
State
profiling
and
verify
this
proof.
Do
you
have
some
results
in
terms
of
I
mean
CPU
cost
or
gas
cost
for
your
for
your
Bridge,
because
I
know
it's
really
complicated
and
it
takes
a
really
long
long
time.
H
H
You
know
everybody
has
some
new
validation
method
that
seems
awesome
and,
like
there's
a
bunch
of
abstract
stuff
happening
here.
It's
new,
it's
better,
it's
great,
but
the
majority
of
almost
every
system
that
exists
right
now
still
has
upgradable
contracts,
where
the
mutability
for
that
contract
basically
underlies
the
security
of
the
system.
So
do
you
all
agree
that
most
of
that
reduces
down
to
like
the
trust
Assumption
of
the
multi-sig?
H
Is
there
still
this
issue
of
like,
especially
when
you're
expanding
to
like
very
long
tail
stuff,
that
validator
sets
actually
have
clear
incentives
to
be
adversarial
to
each
other,
like
there's,
no
reason
that
validator
set
shouldn't
sign
or
generate
a
forged
block,
because,
like
imagine,
competitors,
arbitment
optimism,
BNB
and
polygon,
or
whatever
we're
like
it's
actually
very
strongly
in
their
interest
to
hurt
the
other
chain.
Yet
they
have
no
economic
incentive
tied
to
let's
say
a
block
of
a
forked
chain
that
they're
presenting
is
a
valid
proof.
Yeah.
Those
are
my
questions.
H
A
C
A
D
I
also
think
multisigs
are
bad
yeah,
huge
props,
to
hop
in
across
for
not
having
a
group
of
great
a
couple
contracts.
That's
huge
I
think
for
the
ZK
stuff,
since
it's
all
like
very
neat
technology
honestly
for
a
while
there
are
going
to
have
to
be
appropriate
guard
rails
and
I.
Think
like
a
lot
of
the
ZK
evm
teams
are
thinking
through
a
lot
of
the
problems
or
like
solution
potential
Solutions,
including
time
lock,
upgrade
where
you
know
you
can
with
emergency,
withdraw
and
things
like
that.
D
D
D
Yeah
totally
and
then
yeah
in
terms
of
like
the
long
tail
of
this
stuff.
Okay,
I
think
yeah.
That's
a
really
interesting
question.
So
in
the
long
long
term,
if
you
have
a
ZK
validity
proof,
so
right
now
proof
of
consensus
only
proves
like
header
validity,
but
you
know
with
zkevm
you
could
even
have
state
transitionability,
and
then
it
doesn't
matter
if
the
validator's
set
necessarily
goes
Rogue
because
well,
the
validator
set
can
go
Rogue
and
sign
a
totally
invalid
block.
D
D
Think,
if
you're
trusting,
if
you're
using
a
long
tail
chain
and
you're
trusting
their
validator
set
to
not
do
malicious
things
like
I,
think
if
the
validator
set
signs
off
on
some
totally
incorrect
header
for
their
bridge
to
hurt
her
competitor,
I
think,
ultimately,
they're
actually
hurting
their
users
a
lot
more
and
so
to
me,
it
seems
like
just
a
bad
strategy
for
them
to
do
that.
Like
I,
don't
necessarily
know
if
they're
super
incentivized
to
do
that,
but
I
do
think
it's
important
like
I.
I
C
A
A
You
know
again,
the
lindiness
is
I,
think
important
here
too,
but
you
yeah
it's
hard
and
again
you
go
back
and
even
when
Chris
says
like
okay,
some
of
these
Roll-Ups
are
pretty
new
technologies
right,
even
using
the
roll-up,
not
even
not
even
being
an
LP
has
some
not
zero
and
potentially
relatively
significant
risk.
So,
like
what
does
it
mean?
To
put
you
know,
10
million
bucks
of
eth
onto
a
roll-up
that
still
might
not
fully
have
fraud,
proofs
implemented
and
all
that
kind
of
stuff
like
there.
A
D
Also
under
discussed
Roll-Ups
also
have
Smart
contract
Risk.
By
the
way
like
people,
you
know,
say,
bridges
are
so
terrible,
they've
gotten
all
these
hacks.
All
there's
been
all
these
smart
contract.
Hacks
and
Roll-Ups
have
the
exact
same
problems
like
the
recent
binance
hack,
which
was
like
a
Merkel
I,
actually
don't
know
all
the
technical
details,
but
from
my
understanding
it's
the
Merkle
inclusion
proof
hack,
like
you,
could
have
the
same
thing
in
a
roll-up
native
bridge
too,
and
so
that's
not
to
be
under
under
counted
absolutely.
E
D
I
yeah
I'm
not
super
familiar
with
this,
like
shared
validator
set
thing
I'd
like
heard
a
little
bit
a
bit
about
it,
I
should
probably
read
more
I
think
as
long
as
you
know,
I
think
at
the
highest
level.
Basically,
you
can
think
of
like
how
would
a
node
validate
that
you
know
a
particular
chain
has
come
to
consensus,
even
if
they
have
a
shared
validator
set
and
then
ultimately
you're
taking
whatever
computation
like
a
node
would
do
and
then
you're
putting
that
in
a
snark.
D
So
there's
no
like
fundamental
inability
to
do
this,
even
in
the
even
if
you
have
a
shared
validator
set
like
you,
can
always
do
this
I
mean
okay,
it
might
be
a
little
harder
to
keep
track
of
the
validator
set
if
it's
like
rotating
across,
like
three
different
chains,
or
something
like
that
so
I'd
have
to
like
look
more
into
the
details
and
actually
honestly
the
details.
Here
are
often
what
really
get
you,
but
theoretically,
I.
Don't
think
there
should
be
any
like
trouble
with
it.
A
Yeah
I
think
just
the
way.
I
would
reason
about
this
and
again
it's
not
there's
a
lot
of
new
stuff
here
and
a
lot
to
wrap
your
head
around.
But
the
way
I'd
reason
about
this
is
like
I
figured
with
Zuma
or
Guillermo's
earlier
Point,
it's
the
minimal,
like.
What's
the
lowest
common
denominator
of
security,
you
have
here,
and
so
you
know
in
our
like
optimistic
design.
All
you're
doing
is
saying
hey.
This
happened
on
this
other
thing.