hi I'm beyond and when it comes to
bridging that AB talk contracts talking
across chains so I will use the next
half hour to tell you a bit about a
project if you know vajay overview on a
project that we kicked off roughly one
and a half years ago in the larger
context of another poem project which we
call polka dot to really understand what
we're trying to do I want to give you
just a brief brief gist of polka dot so
polka dot is our take on a
next-generation blockchain protocol with
key tenants being scalability
interoperability and governments it
really is
heterogeneous multi chain proposal a
framework that is set to enable
independent blockchains to exchange
information and value in a trust free
manner now for this larger vision to
become a success we need a component
that we call the birch and the bridge in
that context it's supposed to enable
block chains that ourself secure that
means that provide their own means to
come to consensus to really communicate
with each other now when we started with
that project we realized that we really
got an opportunity to create value for
existing aetherium developers rather
than shooting for the moon in a few
years and in order to understand in what
way this can help a serum developers
today it's important to understand the
problem that we are facing today those
teams that building dabs today and I
mean most of you are aware that the name
of the game is scaling right we still
haven't figured out how easy remain that
can scale and I personally at least am
very skeptical
saspa will arrive within the next 12
month and I think Edward rather take a
few years until we really get them and
what we've seen over the last years is
that we have this amazing ecosystem like
hundreds of projects that have been
working hard on implementing certain
depths right certain depth with a
certain smart contract architecture and
it's sad but the reality is that a lot
of them can't go live today on maenette
because transaction fees are
prohibitively low prohibitively high so
the depths are economically not feasible
and second we get into these situations
where the network is just congested
right the blocks are full and some
people may say right but you know we
have all these other EVM scaling
approaches right that can potentially
help us today or rather in a few months
when they're done and a lot of them we
we call Lea do scaling solutions right
so we have one to run micropayment
chairman it's such as micro Radin or we
have state channel approaches from the
wonderful team from fanfare the january
state Senate from counterfactual or the
great work that spank chain has been
doing and last but not least just plasma
right but what a lot of people forget is
that those approaches are not applicable
to most dab architectures that exist
today so these teams that have set out
like a few years ago when these ideas
weren't around yet right and have
written like hundreds and thousands of
lines of code right I in a situation
where they're like if we want to use
these approaches these layer to scaling
approaches that really means they have
to start from ground zero
they have to react attack their hold up
so and that is what I believe parity
bridge can at least help until in the
intermediate time until chess pass
around right so let me introduce you to
what that
paraty bridge basically it's a federated
system that allows to relay arbitrary
messages any kind of messages between
two evm networks between two EVM chains
for the sake of this presentation here
let them call the main and side chain
right so we have two there are three
critical parts of that verge that exist
today one is rust software that connects
to two aetherium nodes via RPC or IPC
you can choose and really just watches
the chain for certain events to be
triggered then second there are
mid-space entities persons that run the
aforementioned software and they are the
authorities that validate and eventually
relay the messages from one chain to
another and last but not least we have
smart contracts on both chains that
coordinate between validate between
these authorities the validation the
relay and eventual delivery of the
messages now what can you do with them
right that's that's the biggest question
well the nice thing about that is this
general approaches that you can have
adapt that has a smart contract on one
chain that suddenly calls a function on
a any contract with any parameters on
another chain it's that simple and
security of that message relay is
guaranteed by trustworthy authorities so
for every and each message that's being
relayed it's required there's a that a
certain number of authorities have
signed off of that message relay and
overall we try to keep the system as
simple in general as possible right now
how can that help mitigate these scaling
issues that we run into well if you can
offload a large amount of transaction
from one chain to another right that
that is an approach you can choose and
really what you can do there now because
of this arbitrary message relay approach
is you can spread out you dab between
those multiple chains so you have the
assets that need to live on main that
right on the assumed name that may be
those that have to be interact with
exchanges or maybe some identity of the
user that can stay with us right but
those interactions within the apps that
happens on chain right that are really
computationally expensive or we try a
lot of transactions those you try to
outsource to another app so that's one
part the other exciting part about that
approach is in my opinion that you can
really get early access to new features
features that are have yet to become
available on the main net so if you take
as an example that the sidechain is
being run by parity theory nodes right
in a pure network you could have today
wasn't smart contracts being run down
you could use private transactions or
you could try out constantinople opcodes
that will only become available in half
a year in general when you Maynard
upgrades there's one note of caution I
wanna I want to add here and that's very
important to me why this is really great
for the moment in the long run
this isn't gonna solve the scaling issue
in in in the hole right that's why the
slide says mitigating scaling issues and
not solving them because what that means
here is that you know if you spin up a
new side chain that means you also have
to secure that chance I chain and as
more side chains are as more resources
you need to secure these individual side
chains and we all believe that that
can't skate securely nonetheless in the
meantime this is a way to get your
application life
so for the sign change what options do
we have
I believe you can choose between three
flavors right now either you say hey you
know I need the the transaction
throughput that's available on a new
change for myself for my own app in Pepe
or a parity theorem you can get up to
maybe 500 maybe one to two thousand
transactions per second and then you
just say like hey I spin up my own def
specific chain you get a few different
projects to run an authority note and
thereby secure your chain or you say no
actually you know this is as a team and
we have like applications that interface
with each other that are reliant on each
other and we both make a consortium and
we spin up our our kind of deaf friends
of dabs chain or last but not least you
use an existing bridge that verges
existing networks for example the easier
main network with the cove intestine now
let's take a look how parity bridge
actually works the next few slides will
show you what a walkthrough for message
being sent from main tree send what you
can see in these diagrams is on the left
side there's a main chain on the right
side there's a side chain on the main
chain you have a contract deployed
that's called which contract right now
it has one function that's called relay
message on the side chain you have a
bridge contract as well
right and it's called it has a function
called confirm message now some app
wants to use this bridge what the Deaf
does it deploy is extension contracts so
contracts that know how to interact with
these bridge contracts so we have on the
left side
sending contract which is part of your
DAP it has some function and on the
right side we have
on the sidechain a receiving contract
which is also part of your application
and which has a function accept message
now we also have bridge authorities
write these in take this integral part
of the system that actually facilitates
the message relay between the two chains
and that watches both chains now let's
say a user kicks of a transaction with
your application it called some function
and some function again called relay
message because I wants to send over a
message to the other chain that again
kicks off it triggers an event called
relay message the Bridge Authority see
that event being triggered they wait a
few confirmations because they want to
wait until they have a higher degree of
finality right because the main ad it
has only probabilistic finality and you
really don't want to relay a message
that might be reverted after the fact
right so after a few block confirmations
the authorities confirm the message one
by one on the other chain once a certain
threshold which is configurable has been
achieved another event is triggered
which is receive message and then this
contract the bridge contract on-site
chords whatever the recipient contract
is and calls a function called accept
message there that's a message delivered
and it there can be whatever transaction
should be kicked off by by this
interaction can be kicked off by accept
message sign so that's add the message
relay the other way around from site or
main is not identical to this
interaction and that is mainly due to
the reason that we build on the
assumption that transaction costs are
significantly higher on the main side
than the side side and that means you
know bridge outside is real
we want to interact as little as
possible with the main blockchain and
like gather signatures gather these
confirmations on the side chain so how
can you utilize it as the app developer
like what do you have change them and
critically there are two interfaces that
you need to be aware of you can see both
here one allows you to relay a message
it only has two parameters it's a data
whatever your messages as well as a
address which is recipient address on
the other chain also you have a function
called accept message which your
recipient contract has to implement
right and that's it one thing is to be
noted here all information obviously
needs to be encoded in the data
parameter and the recipient contract
needs to be able to decode that message
and do certain actions based on this
degradation now I brought you a few
examples of what you can do with them so
for example you can use to build an ELC
22 s and C 20 bridge you look up you
build for example let's take organ as an
example you build a contract that allows
you to lock up orca on IEP on the main
net that contract sends a message
through the purge to another contract on
the side network and says hey you know a
sign that many or got oaken's that only
live on the side network to this person
and vice versa
pretty straightforward as well you can
do that with native currency so on the
manor you could look up ether on one
side and create rapt ether on the other
side which is really an ESC 20 token
that is redeemable for one ether on the
main network and the last example I
brought here and that's the one I'm most
excited about probably in the
in this combination here is that you can
have an ESC 20 token on the main network
lock it up and then if the user whoever
locked it up native currency on the side
network and that really means you
suddenly can have a stable coin peck
native currency on the sidechain right
you can have died being essentially the
currency that you used to pay for gas on
your side network and if you combine
that for example R is fixed gas prices
you suddenly have a situation where
those people that run dabs are those
people that interact with stamps on your
side network have full control and full
understanding of what their transaction
and their interactions will cost
there will be no volatility and this
last part really was made possible by
something we called la cravat contract
which allows a smart contract to inform
the consensus engine how many new tokens
should be minted and who they should be
assigned to but basically the options
are pretty much unlimited of what you
can do everything you can write in a
smart contract you can do them now here
a few of the projects I've personally
talked to that have either been using
the parity bridge or that have been
waiting for the arbitrary message
passing in order to you know split up
they're there between multiple chains
now as always there are certain caveats
with this approach and they occurred
certain cave reads with our current
implementation that I don't want to not
talk about so number one currently all
of the bridge authorities right these
authorities that relay messages should
also be authorities on the site network
so they should be the validate as a
block producers of new blocks on the
side chain that is because
currently the system is designed so that
most transactions that happen on chain
happen on the site network and you don't
want the authorities to have to pay for
these transactions right for both
reasons spam protection as well as cost
but if the British authorities happened
to be the POA or authorities on the site
network they don't have to pay for the
transaction that they put in their
blocks so that works pretty well in my
opinion it also works pretty well with
the trust model that you have to assume
around this application because you know
after all if you don't trust the
authorities on your site network you
know truthfully maintain integrity of
this side chain right then you also
wouldn't want to trust a bridge that
relays messages through this chain right
another one currently the spiritual
authority set is immutable right it's
very trivial to change that we can just
add another contract logic that allows
you to have a majority vote and vote a
bridge authority in or out however you
want or add whatever it's governance
mechanism you want last but not least if
you connect two chains and one of the
chains is a proof-of-work network then
unfortunately you are facing the problem
that you don't have deterministic
finality which means if you want to be
fairly sure that nothing is being
reverted you want a very weight of huge
transactions and that introduces lesson
let and see that we don't want that sad
if you've got two networks that have
deterministic finality there's really no
no reason to wait longer than ones
finality has been achieved on any block
last but not least there's a very
important note of caution here the
contracts I've been talking about here
they haven't been audited yet so please
use with caution they in an alpha phase
right
so further challenges transactions on
Maynard are very expensive right so if
you relay a transaction from the side
network back to the main network then
you need at least one transaction to be
made by authorities and that's the
transaction that actually relays a
message right so now who should pay for
that transaction that's still a problem
we are facing I believe in most cases it
won't be a big problem
because the application that decides to
implement the site network and to
utilize the bridge has an intrinsic
motivation to pay for these transactions
because it obviously increases the value
of the network the overall network and
its application second what happens when
relay message kicks off a transaction
that actually runs out of gas right like
we are facing a more acing situation
here and that's not trivial at all to to
mitigate another thing that shouldn't be
unnoted is that there is still missing
tooling for side-chains right even
though we finally have an open-source
blockchain Explorer which is absolutely
fantastic right which you can spin up
for your site Network we've still met
miss madam asked and if here and other
kind of things that we usually want in
order to effectively build on a network
last but not least there are UX
considerations that you have to take
into account when you follow this
approach for example you might end up in
a situation where the user that
interacts with adapt has to switch
between networks which is not quite nice
also the user might have to own native
currencies on both networks so last
thing a bit about the roadmap that we
are looking at next things we want to do
include we not want to enable
which authorities to vote on a new
bridge authority set what I just said
dynamic bridge authority sense ii what
we really want is that the bridge
authorities are tracking whoever is an
authority on the on the site networks
and that these set are pretty much
identical further we are exploring
methods how the site network can be
proof of stake and the sidechain
validate us you know the validators of
that chain actually state is on the main
net which is a fairly interesting
approach furthermore we are interested
in finding more interesting use cases
writing more extension contracts and
last but not least they are still
chilling that should be in place for
example monitoring tooling that allows
us really to inspect and see what is
happening in the bridge and what
messages are being relayed and debug
problems if there are any problems I
invite all of you to please have a look
at our Vicki Reid contribute shared with
us I can't wait to hear what you want to
build with that and on what network you
want to build it is it coven is that
your own app for specific chains are you
going to team up with giveth or some
other teams to build a new chain in the
meantime as long as the manor doesn't
scale thank you so much
so I've got another five minutes for
questions I can repeat it to you them on
the roadmap I noticed you guys had no
intention to audit your contracts is
that something that you know you're
going to do I'm sorry on the roadmap you
guys didn't list any intention to audit
your contracts is that something that
you guys are going to do because that
hasn't really worked out well in the
past yeah most definitely so what I want
to see first is a bit more
experimentation right we were we were we
haven't actually released arbitrary
message-passing Burchette it's already
in github yeah you know you can play
around with it it works but you know we
want to write a few more integration
tests and then I expect us in the
following weeks to release it then
deploy a test version between Colvin and
maybe Robson right play around with it
invite more people to play around with
it see if it really you know fulfill
these requirements and meets these needs
that people have and then once we got
there sure like definitely either we do
it or we team up with a few teams to
audit these contracts thank you yeah
thank you for the question hey hey
thanks for that Bjorn and thanks it
looks looks really exciting and what
question I had was with the bridge
authorities who do you envision those
would be like what are their incentives
for actually securing those relay
messages across screens across chains
again how to panic punish bad actors
that might seep in right I can envision
multiple scenarios right number one the
most obvious one is the DAP that needs
to utilize the chain right being at
their own chain or the multiple depths
that want to spin up their own chains
they have an intrinsic motivation to you
know facilitate this transfer and after
all the price isn't really the problem
the cost the expenses to spin up a node
today I believe for its nearing may not
cost like what $150 a month
geronimo note so
that isn't really the point and to my
knowledge I think POA network has been
running the bridge for over half a year
now and I think the cost were negligible
so reason I ask is one of the most
exciting use cases which I've thought of
with something like thunder core
something like that being able to use
die sound one side chain and move it
over you know you can end up if some
application becomes really valuable or
really of hot use right these bridge
authority czar going to be presumably
taking and Diet and being able to direct
it in the main chain you know there
might be a lot of valley moving from one
chain to another that's it right
and so obviously there's an incentive
might be an incentive there right for
you know then to direct die to some
other contract that's not the intended
intended contract right I can sum
multiple aspects right I still think
this is only an intermediary solutions
as I said because I think we need to
come to a point where we pull security
for all these chains right this booty
chain future where you have like
thousands of chains that all secure
themselves bid in in in this model right
well you have IBM chains being bridged
by parity bridge or in the cosmos model
where you have all these zones that have
to secure themselves I don't I don't
think that's feasible in the long run
right for me this is really an approach
for all these applications right now
that are facing these issues that they
have been working on all that code for
like multiple years and they are facing
the situation a either you wait another
three years and Jasper's here or you
restart from scratch and try to
implement it with layer 2 solutions such
as state channels right that said I'm
not quite sure if that click are you are
you asking about the the danger of
having too much there you locked up in a
POA chain
well it's well maybe not necessarily POA
but for instance like you could mint dye
on the main net right and then there's
some application that uses dye say on
another chain maybe it's like a
proof-of-work saying or a peewee powder
or something right and you send you know
I don't know a million dollars into the
other chain right through the bridge
value gets generated there or whatever
then you want to secure it back on the
main net
you know destroyed or properly accounted
on the main net but maybe it's just not
the youth the right use case for this
kind of okay I get so so you're asking
how can I trust these authorities
effectively because they can send the
diet you know wherever right that's
always the case right like it's it's the
same thing as in in any theorem proof of
work or in any kind of proof of state
system how can i sir I I trust that the
validators who validate my chain be the
chain or or the bridge doesn't really
matter in that sense right like don't
collude right don't build a cartel and
say like oh I'm actually gonna take all
the value out of that bridge very good
question I think like as a user you've
got to be really cautious to interact
with certain chains with too much value
right I wouldn't want to transfer a
million died over to a chain that I know
is rarely being used where there may be
two to authorities only that have
aligned incentives to actually collude
and steal your money right yeah thanks
for that appreciate it thank you thank
you so how is the fault tolerance
maintained at the delivery of the accept
message is there a ring signature or
something of the validators no so what
is happening the Bridge Authority is do
two things right when they watch message
coming from me into a site on the site
matches they all have to call a function
on
sight network right and you have a
configurable section and if you say
seven out of ten authorities have to
sign off on the message only then the
message is actually being relayed
otherwise not right and in the other way
around
you gather signatures before right
they gather signatures on the side
network and then the last or ''tis
submits one transaction on the main
network that accumulates on all these
signatures and the contract checks that
all the signatures are there in that way
you have like for tolerance okay is
there is there like like on state
channels where there's kind of this like
the waiting period after message has
been relayed is there something like
that so that maybe somebody can bring in
attestation saying that actually that's
not what happened on the opposing chain
currently not because really you take
these the set of which our sorties as
you are you know your point of reference
if they say hey that message was real
that is actually relayed and in order to
make sure there's no reorganization they
wait a few confirmation block
confirmations in order you know to be
sure that actually whatever kicked off
this relay happened on the one side of
the chain thank you thank you for the
question I got a head off thank you
[Applause]
you