foreign
[Music]
I want to introduce our moderator
because it's not tarun chitra uh
uh this was supposed to be our moderator
but we canceled him because he had to
leave a little early and instead we have
his alt and even bigger brain uh
moderator wait where are we Guillermo
um Guillermo is I want to introduce
Guillermo he is the head of research at
bank Capital crypto uh and he also uh is
a PhD from Stanford like all these other
smart people writes a bunch of research
papers and is going to ask us insightful
and probing questions
to get to the heart of the trade-offs of
bridge design and the future of
cross-chain communication
um so thank you Guillermo for moderating
this well 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
um 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 uh give me a 30-second intro of
who are you what do you do what have you
done to deserve this and what have you
done to be up here
what so I'm Chris Winfrey I'm one of the
co-founders of hot protocol
um so hop is one of the only bridges
that hasn't been hacked yet oh
spicy closing in on uh three billion
dollars in in volume so far
um before I was doing hop I was a
security auditor
um covered projects like opens up one
framework auger dydx uh to Central and
and a lot more is that correlated with
the bridge not being hacked yet or I
think so so
all right I think Hearts unfortunately
you are next sure guys uh I'm heart
Lambert I am the co-founder of a
protocol called across which is a cross
Chain Bridge we'll talk about the design
and how it compares to hop and other
things shortly run me like this yeah
yeah I won't front right here
um uh I am also the founder of a
protocol called Uma
um not this human correlation no
relation
um although there is a funny story about
how Uma heard about Uma early on but we
won't go there uh uh but
um we are an optimistic Oracle Uma is an
optimist Oracle and we use this option
to coraco as a security model for a
cross which we'll get into
um across also hasn't been hacked
um so I think
congratulations I think yes uh so far at
least so far um but we'll we'll talk
more about that design pattern or the
design trade-offs going forward
hi I'm Uma I'm the co-founder of
succinct Labs we're a newer project
company uh that started just this past
summer and we're working on a
proof-based bridge so also we can talk
about the design uh 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 um yeah our bridge is going
to work
cool so um 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
um and there's a bunch of categories of
bridges right so
um first things first I guess can one of
you whoever is feeling the spiciest or
at least spicy depending on your day uh
describe to me like what are the
categories for like what 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 uh 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 I mean I'll shoot and go and say
it and I think you can broadly create
like talk about asset Bridges bridges
for bringing bridging assets between
blockchains and let's call it data
Bridges or messaging layers or arbitrary
message Bridges which are for bridging
data okay our do data Bridges contain
acid Bridges as a subcategory or not
I think there's I don't I think we could
probe that I'm not sure I think it
depends on design I'd argue every asset
Bridge Is underpinned by a data Bridge
okay I would generally argue but there's
sort of some nuances because for example
a cross uses some of the canonical data
bridges too
um to bridge assets
okay so fine so we've been listening to
Bridges and then acid Bridges and you're
right I think you could maybe do a
subset thing here too with like some
caveats or asterix's sure and then on
the acid Bridges I think one important
um thing to
discuss and potentially agree on is
dividing them into wrapped asset Bridges
or what I sometimes call like lock and
mint Bridges where you take an asset you
lock it on its uh home blockchain and
you mint a representation of it on a
destination Chain versus what I will
call like
um liquidity Bridges where there are
canonical versions of the asset on both
the source and destination chain and the
the bridge here functions almost as a
convenience metric or a convenience tool
to easily move that asset from one chain
to another and Chris I want to see if
you in particular agree with this
because I think we are both in the
category of like liquidity Bridges uh
yeah completely agree I think we're both
liquidity Bridges and then I think you
could even break up each of these
categories into a bunch of sub
categories because there's you know tons
of different uh approaches like snarks
the Hub and spoke model and you know the
the one that's been kind of the worst in
terms of security which is uh multi-sick
Bridges
[Music]
okay so fine so you both chose to be uh
what do we call it liquidity based
Bridge the liquidity Bridge all right
fine uh why not for example a wrapped
acid Bridge like does it matter do you
care is it an interesting thing so
um 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 uh 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 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 uh holding all of the
liquidity uh 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
say vertical correctly I think Uma has a
spicy take on this well I want to
interrupt and put a bit little Nuance in
this too because I I want to further
differentiate between maybe nuanced
types of wrapped asset Bridges so
Roll-Ups like Chris's right that when I
want to create uh like a version of
ethereum on a roll up I'm like locking
ethereum on a I'm locking ethon ethereum
and producing that version of it on the
roll up 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
um is the one where you literally do
just like 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
yeah I think your point of these minting
Bridges having more value locked up in
them uh I like to think of it as
basically if you're minting if you're a
minting bridge you have the integral of
all the volume that's passed through
your Bridge whereas if you're a
liquidity Bridge you're going to have
the derivative because at any moment in
time you only need what's going to be in
flight and so I think it's actually like
a much more elegant solution uh to to
the problem because you don't have this
huge honey pot sitting there that's like
waiting to be attacked and even if it is
attacked in liquidity Bridge that's bad
but it's not as bad because you just
have the instantaneous liquidity you
need 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
um 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 so with hop
we we've kind of come up with this like
Hub and spoke model where uh we use
ethereum to pass messages between
um 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 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 uh
liquidity when a user makes a bridge
transfer and then as those uh transfers
happen many of them get bundled up the
Mercury gets to the destination and then
everything is settled and so that's how
we're able to bridge across different
layer twos in a way that that you know
does have the full security of ethereum
if you're using optimism and arbitrum
and then we're able to actually put
these stock gaps between each Network
because we have this Hub ethereum
contract and this lets us support kind
of you know side chains that don't have
the full security of ethereum without
exposing uh users to the risk of those
side chains if they're on a you know a
true roll-up
so essentially but hop only allows you
to do layer two two layer two transfers
or like anything with where you have a
you know one kind of
consensus layer a truth layer so to
speak that's kind of below it so hop can
support any Network that has a message
Bridge with ethereum okay yeah
okay
um heart tell us about so yeah there's
there's a lot of similarities and then
some important differences so across
actually only supports uh 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 uh
destinations
um that can be slow that can be painful
that can actually be quite costly 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 uh
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 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
um you know tvl has a cost of capital
cost of capital
you gotta pay for so if you have less
TVO you have lower fees
um but also you have less security risk
there's just less of a Honeypot so
essentially in your case the protocol
and the relayers themselves kind of act
as like market makers right you know
they are taking on some like Risk in
like kind of doing this optimistic like
fronting there's no like so the the
relayers are effectively making like
two-hour loans right um but that is risk
right there's 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
um uh 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 sure right and like
roughly speaking but it's I still should
be compensated right like in some sense
it's ethereum that I don't have that I
could just like sell or do something
with how am I being compensated for
doing that yes you charge a small fee
okay so it's basically like you charge
like a two-bit fee on this uh 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
um 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 so a kind of interesting
feature of the design is if the relayer
is like a market maker or kind of the
person that's generally doing
arbitrage-like things they could
actually get paid to move their assets
potentially to a chain where they wanted
them just kind of interesting
interesting okay okay and then I guess
we have a bit of a less economic current
Focus Uma but a very interesting you
know bridge design yeah I think our
Bridge
um or what's the Sanctus building is not
a liquidity layer it's not even
necessarily like a token or asset bridge
I think uh we're starting off by really
focusing on the arbitrary message
passing part so I think that's like a
big difference uh 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 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 Bridge contract on ethereum that
users send contract calls to and then a
relayer would send a proof uh 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 start on the topic of trust
minimization which I suspect you have at
least some opinions of
um maybe unclear
um so first things first how does trust
affect kind of the safety of a bridge A
and B uh you know kind of the maybe like
higher maybe mid-width question is uh
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
um Can is it possible to make a safe
Bridge or are you just are we all just
like kind of screwed like is it just
like this like you know sofian task of
pushing a boulder up a hill repeatedly
just to have it hacked or something yeah
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 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 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 you know for
example uh the most best snark based
approach could also have Smart contract
risk
um and so I think it's really important
to like be intellectually honest that
there's risk in both dimensions like
there's risk in the trust model there's
also smart contract implementation risk
how do we reduce smart culture good like
implementation risk like do we what do
we do formally verify everything do we
just go and like add in a bunch of stuff
and say like solidity sucks and we go
and like write a new language that is
like rust or whatever I mean Guillermo
you're the crypto researcher I mean I I
don't I'm like a fake researcher I
mostly do like a bunch of weird math but
I can pretend no I mean I think look I
think that's a whole other uh panel or
conference wide topic of like how do you
write but I'm gonna make you give me
your two minute uh sorry what do you do
you write down the moderator so I can
make it yeah I think you do all the
things right you um you have really good
Engineers that are smart and thoughtful
okay step one you audit your code from
credible Auditors or you are an auditor
and you still hire Auditors so it feels
like an unfair Advantage right that's
fine all right but uh you audit your
code uh 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
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
um because it is very antagonistic
environment out there and so just
surviving I think is uh is is
increasingly uh it just means you're
you're more the longer you survive the
more likely you are to survive in my
opinion
yeah I think there are other smart
contracts out there on ethereum that are
much much much more complicated than a
bridge 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 why hasn't it
been done until now because in my
opinion it's not even the most complex
smart contracts out there you probably
have opinions on this Chris I I
completely agree I I think those are you
know both great answers like we need to
build up our lindiness uh to you know as
as Bridges exist for longer and longer
without being hacked the you know the
more uh we can trust them to not be
hacked in the future
um 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 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 they
are you know uh doing supply chain
attacks where you know introducing uh
vulnerabilities like deep down into your
software uh stack so you know in terms
of trust model it's just you really want
to rely on the smart contracts
themselves for your security
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 yeah it look works
right if that's what you want right and
I think the the other angle to look at
this too from the multi-sig angle is
also censorship
um and Regulatory issues and like wait
can that bridge even get shut down
because someone says Hey a government
says hey don't do this anymore you 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 one thing one thing
you said earlier was that your approach
is trust minimized but I'm kind of
curious why you said that and not
trustless because it does seem
conceptually trustless to me yeah I
think trustless is like a really strong
term and a lot of people have a lot of
feelings about it uh 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 uh
I think it's you know it's not trustless
you're still trusting the other chains
of validators um
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 more generally I asked this
question so I'm going to put you under
that
um but sorry it's just happening sure no
um so actually so the most num in terms
of number of bridge hacks has uh 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 um 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 uh verify our
security variants so you know these
security and variants are you know if if
a token um kind of like starts a
transfer here is it going to be
completed here can you know multiple
completions happen at the destination uh
is there some other way for for someone
to kind of like extract value from the
bridge
um and so if we can you know basically
uh make it as simple as possible to to
uh verify those things the the easier it
is for Auditors to kind of catch any
bugs that might show up essentially like
what you're proposing is
well simplification for sure but also
some notion of formal verification or is
that not actually it I think there's
cheaper ways or more cost effective ways
to to get security than than formal
verification okay 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 it's kind of true
um 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
yeah I guess I'd say like Chris Kirkman
if I'm wrong but I think all the hacks
are actually smart contract tax right
like all of them none of them have been
no I think some one of them the oxy
Bridge was a multi like they compromised
the keys sure so I I should say that
yeah okay fine multi-say compromise the
keys but in terms of like
um like your trust model our trust model
this optimistic trust model that hasn't
been the source of those hacks yet right
yeah so the the uh in terms of value
lost
um it's been key compromises and then in
terms of number of hacks it's been smart
contract vulnerabilities
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
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
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
um 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 so like look I think on the
asset bridging uh 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
um
um I think it's okay yeah trustless and
all that yeah thanks we're all adults
here but um uh so I I think that's
that's kind of interesting like and I
think Chris 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
um 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
um either but maybe go
yeah I agree um you know for an end user
the the risk for a bridge is act at
least for a liquidity Bridge the risk is
actually really really low
um 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
um or in terms of cost you know it it
comes down to like uh 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
um for your security and the cheaper it
is going to be for end users but end
users don't need to think uh too much
about the security of the bridge because
they have such limited uh exposure yeah
yeah 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 know whoever else it's
going to be so I guess well I just
wouldn't add one other thing around this
so like your question was is there like
a winner takes all Market here and on
the one other
concept that I think is worth floating
here is this idea of it around Capital
efficiency where if say for example your
Bridge had required 20 million dollars
of tvl but could do like a billion
dollars of volume a day and you were
able to charge like a basis point on
that
even if that 20 million dollars gets
hacked or whatever there's probably
still a reasonable model in there like
business model where the the the profit
of the bridge it was worth the risk of
that capital and so again I think the
space here where I think the bridge
space has kind of gone in the wrong
direction is like locking up lots and
lots of dollars which is for for well
also not making that much revenue and
like that's us that's you got the ratio
the wrong way around right and so a
winner tick all thing I don't actually
think this is a winner takes all Market
on the asset side I think that
um 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
um 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
well I think of course I'm a snark Maxi
and I want us to I want all day to
transfer to go through you know the
succinct like clients the succinct you
know message Bridge
um you know whether that'll happen I I
think it's hard to reason about I do
think uh one thing I will say is I think
this like snark based approach for
assisting to like clients and proof of
consensus is kind of going to be the end
design of like a data Bridge especially
where if you for example if you like
don't necessarily care a ton about
latency like I don't you know and maybe
you can layer a liquidity Network on top
of it eventually but I think the snark
based approach is technically feasible
like it works today we just need to do
some more engineering and do Implement
proof of consensus for all the chains
and just implement it but it works today
and it's you know I think it is like the
end design like I don't necessarily
think you can do much better in terms of
a trust model
yeah I think we'll probably see a power
law distribution like a lot of other
markets um and the other thing we
haven't talked about is you know there's
a lot of assets out there and it's hard
for liquidity Bridges to support long
tail assets because you don't want to
just like maintain the liquidity for for
an asset that no one's using to bridge
right and then there's also going to be
longer tail networks in terms of uh
what's supported so you know we'll
probably see
um 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 uh they're going to
be focused more on security and and uh
making sure that their LPS don't need to
uh be paid a ton so um I'll bring it
back really quickly to the original
question the reason I asked this is you
know in a lot of ways what are you
paying for when you are like you know
giving a fee to somebody is you're
paying partially for the fact that like
that thing incurs a risk right so in
some sense like security and economic
efficiency are like highly correlated so
you can think of them almost as like one
single number right like I don't think
you actually do better by being less
secure and economic in terms of economic
efficiency or at least not a lot better
right
um 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 uh 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
I I think there's actually three costs
so that there's gas costs um there's
time value money and then there's the
risk that that that
um money is taking Beyond just uh you
know a riskless uh 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
that would be great for the snark-based
bridge that would be great in a lot of
ways
we're waiting for that future yeah yeah
and so it actually becomes a really
complicated question like I don't think
we could uh you know get all the way to
the bottom of capital efficiency here on
stage
um really there's because uh you know
both both across and hop have both
active liquidity and passive liquidity
uh there's different challenge periods
so that gives you know different
trade-offs between
um you know what these different
liquidity providers are are
um kind of taking on
um and then yeah there's also uh 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 uh we kind of think of
capital efficiency in like three buckets
um so we we have like the active
liquidity provider
um that uh Cycles every 24 hours we keep
very long challenge periods because we
think it's important to have like a
human response if if things go wrong
like you that your team needs to be
notified you need boots on the ground
and and you know be able to know that if
your infrastructure is down you can have
your engineers get it back up and and
protect your Bridge
um and then there's the the passive
liquidity providers and so hop uses this
amm model that we haven't talked about
yet and so we we have this like
intermediary accounting asset and we're
able to kind of shorten the challenge
period from an optimistic roll up from
seven days to one day and so that that's
our 24 hour challenge period And so you
can kind of think of the amm look
liquidity as as just taking on the seven
day uh Capital lockup only for the net
flow not the total flow right this is
what Uma was mentioning as well right in
some sense you can think about it as the
derivative of the flow as opposed to
like you know the integral over all of
it but sorry okay yeah 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 uh that kind of
scales to transfer size but not transfer
volume so you know we could have a
bridge that that has uh two amms that
have 10 million uh 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 uh as long as the
transfer sizes are are you know below
what a 10 million dollar pool could
handle 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
uh in is that correct or
yeah okay
so because I'm still on unclear also um
I guess before we kind of get to that
for context 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 so now we're right now we're
talking about like the thing built on
top of like how do you transfer assets
correctly and how do you like ensure
that you can verify that these houses
have been put into one's applied and
whatever
um so let's while we're on that specific
topic afterwards we'll get to the
messaging part which I think Uma is uh
has some other spicy takes on but
um 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 so so
uh the the main purpose is actually to
one kind of uh price liquidity flows
between different networks
um 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 uh lock up for the the total
flow of of assets
and so because we have
um we basically have this uh
intermediary accounting assets so it's
like a h token got it got it so you can
essentially pay to reduce the risk so
like let's say you're waiting 24 hours I
can be like I'm gonna Swap this on some
exchange right which lets me actually
have the native acid and someone else
can take on the risk basically we can
exit our these H tokens in 24 hours
versus the canonical assets um that are
exited in in uh seven days and you know
so it's like eight Chief eth is the pair
and it's basically a market between the
the uh 24-hour exit time in the seven
days got it got it got it so essentially
prices the risk that you are taking on
by waiting whatever seven days to
interrupt your asset versus 24 hours
like yeah as well as uh demand flows
between that's right that's right that's
right yeah the thing I'm just going to
add just maybe zoom out a little bit
um like our take across this take is
that there is this is a financial
engineering problem like if you solve
the data uh 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
um and so you know again hopping across
share a lot of philosophies the the one
thing that we've done that is quite
different 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
um yeah so so like I said the the amms
um it's only based on uh 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 balanced you need
like yeah I'm gonna push back a little
bit because you need the flows to go
both directions right if I keep on
pushing right in the direction you're
going to run out of liquidity or make it
an ordinary expensive and that's why I
say that that um you know hops Casa
capital is you know for the arbitragers
it's it's just seven days of the net
flow so if you know there's a perfectly
balanced flow between arbitrim and
optimism
um we don't need arbitragers at all okay
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 how can you incentivize
netflows and or have a low cost when
there are imbalance flows have the
lowest cost of capital and uh there's
lots of like fun Financial engineering
tricks in that I think but let's maybe
go 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 uh honestly what underpins the entire
Financial infrastructure you guys are
talking about uh 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
that's open source that's just like
classic normal everyone uses it how does
one even monetize this thing
um 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 then that's the
standard yeah I think what we're
building at succinct is going to be like
open source and we view it as like a
public good because it is like a public
good for all these ecosystems to have
these succinct like clients and have
this like snark proof of consensus
um for the consensus algorithms and
honestly it goes beyond just having a
bridge like you can imagine this
actually being really useful for like
like clients and wallets so that you
don't have to connect to a centralized
RPC and you can like do something
peer-to-peer 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
um 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 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
I mean currently us that does this and
then has guarantees around it like okay
if you're gonna rely on our like client
you probably want to you know know that
it's going to have like a 99.999 uptime
and so I think I really view this as
like where what we're building is a
public good of course it's going to be
open source of course it's going to be
audited the more people that can
contribute to it and like we can all
make sure it's like canonical
infrastructure that's really secure and
everyone feels really good about but
then operationally it's kind of similar
to like an open Core Company where if
you have something I don't know like in
the web 2 world like mongodb where
mongodb is open source but you know
the company runs the open source
infrastructure and so I think a similar
business model like could make a lot of
sense here where you're basically paying
for the convenience and like the Peace
of Mind of like you know this
infrastructure is actually going to work
and it's actually going to be uptime
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
um and so it's important that anyone can
actually run the operator themselves
um and yeah I think there's like some
interesting things you can like do
around that in the future is it possible
to tell us but how does one decentralize
this I mean it feels hard right like
you're kind of relying on someone to
reward these things I mean just tell me
if I'm wrong but anyone could do this
yeah it's just the sense that like this
is where no one's going to right other
than if you are in some yeah it's like
we're going to coordinate all this
infrastructure and then you know and
we're going to do it the best so you
have like the like client that updates
the fastest and like you can have like a
nice dashboard 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 a really
similar thing could also apply here
where you're going to have like a bunch
of provers that you know basically I
kind of think of it as there's this
economic exchange going on where there's
people who are relying on those
listening to like clients who want
proofs and then there's people who are
able to provide proofs and there's like
some exchange of value and then maybe
you have like a Marketplace and you like
take some cut of that or something so 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 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
yeah I think expecting individual users
to generate these proofs is totally
infeasible like I think to make it you
know timely uh you need like custom
Hardware probably and like the limit uh
generating the proof takes takes a while
um how long and then what machine sorry
So currently for ethereum our proof of
consensus for ethereum takes like four
minutes to generate on like a pretty
beefy AWS machine I think that time over
time that time it takes to generate the
proof will definitely Trend um hopefully
closer to zero
um but you need like GPU or there's a
you know a million ZK Hardware companies
that I'm sure will use that's going to
make it better but again yeah a user is
not going to run a ZK fpga in their
house like that doesn't make sense
Jeremy will yeah yeah gotta minimize
that trust you know truly minimize it
but yeah the beauty
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
cool
um I guess we are like almost getting
down to time uh unless there are any
last burning thoughts I think I will
turn it over to the audience to see if
there are any questions are there any
last burning thoughts ideas Notions
constructions let's get some questions
all right let's open up some questions
do you need a uh you first but
uh
or you can shout and we'll repeat them
too
hey yes I have a question for Uma uh
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 uh
well it maintain the like uh relayer
like or like validator
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 uh for
us like the block propagation time is
first we need to wait for ethereum to
finalize uh 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 uh so that
takes you know another four-ish minutes
right now but I think that can go down
quite significantly to hopefully someday
on the order of seconds
um so hopefully that should be no issue
and you can probably do things around
not having to wait for a finality
um that I won't go into now but I think
in the future that's also possible
um 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
um just you know and so there's like an
extra 10 minute delay on your Bridge
basically um 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
yeah I still miss some of this stuff
earlier offline but basically it's like
12 to 16 minutes you can send blocks and
it costs you like 180k on the
destination yeah yeah verifying our
proof uh so verifying approved there's
like pre-compiles for pairings and so
verifying approved takes like 200k ish
gas so you have like 200kh Scouts to
verify a proof and then you have
um like whatever smart contract logic
that's should be quite minimal because
you generally try to stuff it in the
snark
um to you know keep the like client up
to date and then there's some really
really fun things you can do with the
recursive snarks so say I'm bridging
from gnosis chain polygon and you know
whatever other chain and I have proofs
of consensus for all of them 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
you're talking about the proofs proof
generalizer for example for ethereum to
uh 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 uh for your for your
Bridge because I know it's really
complicated
and it takes a really long long time
permission currently takes four minutes
um so it's like on a pretty beefy CPU
um and then the gas cost to verify the
proof like because it's a succinct proof
no matter how much computation you stuff
in there it's always going to be like
around 200k gas Brian
um three quick Rings jeremont like
pretty timely comments on IBC you should
check Twitter after this it's like a
Grim Day for IBC right now um but two
other questions
um one first
there's a lot of new
um 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 that's
controlling the upgradable contract and
the second question was for Uma
um in a world where like all of the hard
Technical Services recursive State
Journey you know all of this is perfect
and fine 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 uh because like imagine
competitors
um 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
um yeah those are my questions let's do
the first one first so I I Brian I think
we're philosophically aligned like
upgradable contracts bad right
um and they're they're I think there are
things you can do where maybe there's
like an upgrade path maybe kind of but
generally speaking no no no like make
immutable things and that does make your
upgrade path very painful right across
that V1 and V2 and it sucked it really
sucked uh going from V1 to V2 but like
you did it and works
um and but like again
like okay I don't want to shoot on chain
link because that gets me in trouble but
like there's still a multi-sig behind
all this stuff too right and so there
are the thing we also have to realize is
like indefine in crypto there are these
very scary multi-six that are sitting
around that could do very bad things and
um we I think like Uma spicy take his
multi-swicks are bad Chris same like
just those are bad like delete multi-6
uh should be the mo
yeah I agree um hop is also not
upgradable uh we take the the kind of
uniswap approach of launching a new
version and everyone can still use the
old version it's going to exist forever
and yeah
and then yeah Emma you want to go on
well you can you can insult multi-six
too that's okay yeah I also think
multisigs are bad uh yeah huge props to
hop in across for not having a group of
great a couple contracts that's huge uh
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
um 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
um so I do think it is important to have
a balance of like non-upgradable is the
goal but when you're working with really
new technology like you definitely do
have to keep the guardrails in mind uh
so I think that's pretty important I
think
it's definitely a trade-off yeah yeah
well and be like it could be a little
bit more nuanced than that too like a
guard there's there's designs I think
that exist where like it's not
upgradable but there can be like a way
to like a stop button like yeah like an
emergency shut off type thing and I
think patterns like that are not crazy
yeah yeah totally
um 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 but then if you
verify validity proof of the state
transition then you're not going to
accept it I mean that's very far off in
the future
um and then it you know if they have
like slashing conditions on their own
chain then you know they also are
subject to that I 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 think for us like that's why we are
focusing our initial thing we built is
like for ethereum where you know it is
actually extremely decentralized they
have a ton of Economic Security if you
validate ethereum's validators they're
not going to go Rogue in this way so I
think like that's kind of our initial
starting point of focus and again for
users of bridges It's always important
to remember like if you're bridging
between chain a and chain B your
securities the minimum of the chains
you're bridging between and like you
can't get around that no matter how
secure your bridge is like if you even
have proof of consensus and validity
approved
um so yeah I think that's always
important to remember
my question is do you think the user is
special for the liquidity Bridge are
pricing correctly the risk that the
bridge has and if no like what can we do
to better educate them
I I think if you're a liquidity provider
and you're taking on the risk of every
single bridge that that
um or sorry every single Network that
that bridge supports
you are an incredibly altruistic person
but to your question like I think the
users here again to Chris's earlier
point the users here are not the ones
with at risk
um say what
the liquidity providers do have risk and
pricing that I think is something that
is like hard
um you know again the lindiness is I
think important here too
um 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
um 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 we are and
that's not an insult I'm just I'm just
saying that um we're we're there these
are still cutting edge Technologies yeah
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 and
there have been uh things reported not
exploited hey that was awesome and uh I
hope this is not too open-ended of a
question but do you have any comments on
shared validator sets like are kind of
being introduced to Cosmos and are in
polka dot and how that might affect the
architecture of like the proofs that
might need to be generated for a bridge
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 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
um but theoretically I don't think there
should be any like trouble with it
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
um 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 you have to trust the
initial source and if your shared
validator said
is better great if it's worse great like
you kind of just kind of be sort of dumb
about it and be like are you trusting
the consensus that this thing is reached
I don't think I know enough about shared
validator sets to give a good answer
all right well with that last question
thank you panelists everyone please give
a big round of applause