[Music]
so welcome to uh day day number number
four of death card we use zero in here
we're a civilized company
um yeah no the first day was Day
Zero so
the so so so today we're going to be
talking about scaling and
interoperability and well today in
general we're going to be talking about
ethereum 1.1 and ethereum 2.0 and uh and
the general blockchain protocol related
stuff so first presentation we have is
on scaling and
interoperability so I guess to start off
first of all what is you know what what
is scale what what is scalability what
do we want out of
scalability sure so in an ordinary
blockchain like how every node processes
every trans transaction and updates
every full node anyways processes every
transaction and so uh the scalability
system is kind of limited by the fact
that every no needs to do everything uh
so what we want to do is relax that
assumption but still have the properties
of consensus uh like you know non-
repudiation like Source authentification
of contract calls Etc uh and so
scalability Solutions are kind of trying
to make it so that not every node
process is every transaction but that we
still have Security in some
way so you know you know right now with
uh just for for statistics right now
Bitcoin we you know one transaction per
second MasterCard processes 2,000
transactions a second if Bitcoin goes up
to that level then we'll basically have
full nodes processing 1 Gigabyte every 3
seconds so you know not ex not exactly
sustainable for any kind of normal
computer so we'll have 10 full nodes
yeah 10 full 10 full nodes uh and
they'll probably won't be run by
blockchain that info and coinbase
they'll be run by Amazon and Google who
you know people seem to consider as
being more evil than than good local
companies so yeah what we want is we
want a we basically want a system that
work we we you know as Dominique
Williams from Pebble put it we want a
system that works by scaling out and not
by scaling up so instead of making these
big instead of making the system
continue working by having full noes be
more and more powerful you figure out
some way for it to work even if no
single node processes more than a small
small portion of all the transactions
another way you see that is instead of
just stacking blocks on top of
themselves in one chain we we hope to
maybe have like another architecture or
not all blocks go in the same
chain so so right now what we have as
far as scalability goes is the scale up
approach which is you know we have like
we say okay the blockchain is going to
grow a really big but we're going to
make sure that like lines can still be
secure and that kind of works until of
course it gets way until of course the
whole thing just gets way too big and
and it might not and there might not
even
be like it it might not even be possible
for a single node to process all crypto
transactions that people potentially
might want to do especially if we start
thinking about crypto not just as a
payment system but also for a whole
bunch of these DBS and also for like you
know not just people but also for
programs and
Hardware um so there's basically three
broad classes of scalability approaches
there's building on top uh kind of
scaling one
chain uh by sharting the state space and
having multiple cons multiple
blockchains and interfacing them to gain
some of the properties of one blockchain
so we're just going to kind of go
through them and talk about kind of the
state of the of research on those topics
and what the tradeoffs are and maybe
what the disadvantages and advantages of
each approaches so start scaling on top
to you want take it away so build the
idea with building on top is basically
you know keep the blockchain exactly as
it is but we try and figure out some
ways for as much stuff as possible to
happen off the chain but still be
secured by the chain in the long term in
some
fashion so this is one the the one sort
of the first practical example is uh
this well I guess micro payment channels
is actually one that you don't even need
ethereum for you can do it on Blown
Bitcoin and uh the way that works is you
there's a sort of special two-party
protocol that you can do use to create a
sort of it's called a micro payment
Channel going from a Tob and the idea is
there's sort of two there's a two-party
protocol for updating the channel so the
channel starts off containing some
quantity of some quantity of Bitcoin
let's let's say 1 BTC and it and a
initiates the channel it starts off with
a you know a puts a Bitcoin into the
channel channel starts off giving the
entire Bitcoin back to AEG and then
there's a sort of off offchain update
protocol where the channel updates the
say 99 to 8.01 to be 98 to 8.02 to be
and so forth and the idea is you have a
network with a bunch of these channels
and if you want to make a payment you
just sort of find a path going through
all the channels update all the channels
along the way and you use the blockchain
only for like eventual settlement when a
channel fills
up probabilistic payments yeah so
probabilistic payments basically work by
okay say for example for a CL storing
application instead of pay making a
payment on the Block chain for every
file transfer that you do like every
upload or every download what you do is
make a payment with provably with some
probability so that uh the people still
have the same expected re return from
sharing those files but you don't put as
many things in the blockchain kind of
the isue with that is that increases
volatility of the return but over time
it should kind of be the same and
there's much less stuff in the
blockchain and just as a so that's so
those two approaches work for payments
um a third there's also a third category
which is this idea of offchain auditable
challenge response computation so just
as an example of that there's in in some
cases there's going to be a lot of
computations that need to have the
security of the blockchain but which
which might be too expensive to do on
the Block on the blockchain itself so
what and so the property here is the so
the data the data involved in the
computation doesn't is not necessarily
too large but the computations are very
large so zero knowledge proofs one
example so something like you know
verifying verifying skip takes 6
millisecs inside inside of C or C++
might end up taking you know 60 Mills
inside the ethereum J jit VM another
exam truth coin is actually another
really good example because what they
need to do is they Bas truth coin is
like this decentralized Oracle that like
does sort of shelling coin like stuff
but for many bets at many decisions at
the same time and the way it works is
you actually is that it uses these Ma
algorithms to try and figure out who
sort of which voters are more sort of
globally compliant with the entire
consensus so they can reward them more
in order to and doing that Matrix math
as you know takes uh o of En cubed
operations which you know for fair large
matrices is pretty expensive Yeah so
basically the idea there is that the
blockchain ACT has a something for
punishing these oracles if they uh don't
come up with the right result then you
can basically check it on blockchain and
like remove a security deposit from them
uh and if they do then you don't need to
do anything and and the computation
happened off chain so basically on chain
everyone does everything and so you
don't you only really need that for when
things go wrong that's kind of the
Paradigm there yeah so by so it's sort
of by default by default you trust but
you have some period during which anyone
can challenge if someone Audits and they
find something wrong they can sort of
pull the computation down on the
blockchain and if that ends up being
wrong security deposit was
lost cool yeah so we're going to move to
um sharting sure so sharting sure so uh
one idea for blockchain scaling is to
take kind of one blockchain and take
this state space and split it up into
subspaces uh still have the same digital
asset on all the subspaces and have a
protocol for moving funds and doing
contract calls between the subspaces as
well as a protocol for making sure that
all subspaces have enough nodes in order
to not introduce any bti state
transitions so the general sort of
intuition is that if you you could have
[Applause]
make a new pad so the to is you have you
have a bunch of a bunch of sort of
substates you can think of them as being
vertices and they're arranged in this in
this some kind of you know dense graph
structure so you know we talked we
talked a bit about graphs yesterday but
and uh then you have a sort of a sort of
header chain in the
middle and so the idea is is that you as
if you are a miner on this kind of
system what you're actually doing is
you're mining an edge so so when you
mine an edge what you what it means is
is that you can process transactions
that happen inside of here you're
processing transactions that happen
inside of here and you're also
processing the movement of messages
going from here to here and from here to
here so let's say if you have a sort of
multi-chain dap or if you that that has
some state in this in this little sector
and some state in this little sector
then it sends Alpha message and the
message gets stored in in the outbox
here eventually someone mins this Edge
when someone mines this Edge it gets
kicked out of the outbox here it gets
moved to the outbox here when it this
Edge it gets moved from the out box here
the out box here and eventually sort of
makes its way over here and then for the
header chain here the idea is that
basically all of these sort of Mind
edges all make their way into the header
chain and the header chain just sort of
maintains the global order of what or
order of the of the entire thing just by
keeping track of all the headers yeah
and so the reason that the header chain
is really important for this type of
Architecture is that because everyone
uses the same digital asset uh if you
were to have say one of these uh one of
these substates not really coordinated
with the other ones you can have one
substate that has much lower security
than the other ones and then you would
basically by introducing a qualy state
transition in that substate uh impact
all the other ones because they're all
using the same digital asset so uh the
the fact that everyone shares some piece
of consensus is important because that's
what you use to make sure that kind of
all your checks to make sure that you
don't have insecure substates uh occurs
right yes so we call this kind of like
the fragility problem if something goes
wrong in one substate and not every node
is processing everything so for any
given noes perspective you'll never know
100% that something didn't go wrong in
one of the substates that you didn't
process yes what you can do is kind of
challenge response protocols right so
that's the first approach
so the idea behind challenge response
protocols is that if you think about a
block a block you have a header then you
have you know some set of transactions
and then you have a state tree over here
then there's some subset there's going
to be some subset State nodes that the
block ended up ended up modifying while
while processing or processing each one
of these transactions so what you
realize is that if a block is invalid
then what that means is first of all you
know it could be just be that the block
is badly formatted which is just very
obvious to detect but it could also mean
that one of these transactions at some
point
has has some State transition that's
invalid and so the idea is that if an
attacker makes or if an attacker makes
some kind of a makes a block on one
chain and that block and that block is
invalid so first of all if the block is
actually invalid then what you can do
what the some good guys can do is they
can Pro they can basically provide a
miracle tree proof of the exact set of
changes that transaction was supposed to
make and people can re can see that the
changes that the attacker made are not
the same as the as the changes that the
attacker was supposed to make now the
other problem of course is well what if
the what if the attacker just publishes
a block but does not publish all of the
data so that's going to be it's going to
be very very obvious to people on that
chain but the problem is if the data is
not there then there's no way to come up
with a with a with a direct proof that
it's invalid because there's just sort
of no data like theoretically you know
theoretically if Bill if Bill Gates turn
out to give the to be generous and give
the attacker $100 million there could
theoretically be something legitimate
that happens to give the attacker $100
million but if the attack doesn't Supply
the data then there's sort of no way to
know so that's where challenge response
comes in yeah and so the idea be that if
you issue a challenge of some particular
State transition and the response is
never provided that you kind of would
assume that that state transition is uh
not valid yeah but kind of the issue
with that is that uh you basically
require people to be giving these
challenges and looking looking for where
uh where it went wrong but if there's no
cheating then there's no incentive to do
that uh so kind of an ends up being that
there's a non-zero amount of invalid
State transitions that's one problem the
other problem is this sort of fragility
issue which is that if an attacker DSes
the network then the default default
state is is for blocks to get processed
and therefore know blocks might end up
might end up Surviving whatever the
entire challenge period is without
without getting challenged even if
there's actually something wrong with
and then if you have an invalid
transition that's only discovered much
later then the effects of that
transition could have propagated to many
many things and you know we might have
to roll back like 100,000 blocks if you
want to uh kind of fix that
uh and so that's kind of like bad yeah
so somewhat the somewhat more stable
algorithm for dealing with this problem
is this jury selection approach so idea
behind jury selection is that let's say
that okay I mind this Edge then what the
header CH so then what the protocol says
is okay from every from from randomly
from all of these all these little
substates together I'm going to randomly
select you know 200 noes Bas B weighted
by stake so this is a proof of stake
mechanism there's actually no way to
translate it into a proof of work
Paradigm which which is actually by the
way another reason why proof of stake is
superior but so the idea is you weighted
by Stak you randomly choose some 200
nodes and th and those two and basically
a majority of those 200 nodes have to
sign on the ass sign for the blocks
validity and the way that the and the
way that those 200 nodes know if the
block is valid because you know there
might be a node from here and that and
that node might not be keeping track of
the state at all the way you do that is
that the voter provides the block you
know with the state route transactions
but you know right now in ethereum when
over the network the thing that gets
sent is block header plus transactions
but here the thing that's going to get
sent is block header plus transactions
plus the whatever subset of the state
ends up being manipulated during that
block and then this whole chunk by
itself can be Val can be validated even
by someone who has no prior information
at all yeah and kind of theoretically
that has like no cheating in the
National room because it's basically
like foring a challenge response on
every block kind of yeah so like the
idea is you have in order in order for
an attacker to be able to successfully
cheat on this thing just purely by
statistics the attacker has to have
something like you know 30 or 40% of the
entire the entire active stake in the
network so you have sort of the benefit
of you know only 200 nodes validating
each block but without the cost of their
only being sort of 200 nodes protecting
the system because every node is like
statistically protecting the system even
though it's not actually protecting each
and every time yeah so we have like a
probabilistic rather than deterministic
guarantee but it's still quite good
because you can increase the number of
nodes required and that will make the
amount of stake required to to attack it
lar basically the probability of that
things growing up is like is negatively
exponential in in the number of nodes
involved yeah yeah
so that's one
[Applause]
of so that's the sort of so the last
thing was the hybrid ke approach which
is need a protocol for growing and
drinking the thing so you know you could
fix you could just fix it to 12
dimensions and say okay there's 496
substates but the problem is that you
know what have first of all initially
that 496 is might might be way too
sparse but and then eventually it might
end up not being enough and so you need
one thing that needs to be figured out
is some kind of mechanism for growing
the graph so one option is to just you
know if it gets big enough then
eventually you add a dimension so then
if you're if you just sort of keep on
adding Dimensions the choice that you
have is first of all when you add a new
dimension do you just do you make the
new cubes empty by default and sort of
just use inceptive mechanisms to to to
try and subsidize new people being on
those cubes instead of on other or on
those vertices instead of on other
vertices or you could wait for the each
each substate to have twice as many
nodes as necessary and split each one
into two and basically uh add another
dimension to the hyper he yeah yeah so
the choice is you know do you start a
one empty or do you actually try and
split them in
half um problem with split so splitting
them in half feels more elegant and
automatic in some respects the problem
with it is that you might have daps that
you know were very tightly connected but
now they're suddenly much less connected
and so their gas costs suddenly go way
way up which is kind of annoying for if
you're if the because the contracts are
kind of stupid autonomous agents and
might they have no way of you know
figuring out how to deal with the
problem cool so we're going to move to
multichain Sol so the idea with
multi-chain scaling Solutions is that
instead of taking kind of one consensus
group with one digal asset and trying to
split it without losing the properties
of it what we do is we take many
consensus groups with many different
assets and trying to interoperate them
in order to gain some of the properties
of scalability um so basically there's
different types of interoperability you
can have this type of interoperability
called uh Atomic
interoperability um which is basically
uh based on this tier Nolan
primitive um which is this a really cool
idea where oh
no um You' basically make a contract on
one of the chains that says if uh X such
that the hash of X is equal to some y
that's in the contract is
provided
uh then you would do
something and then otherwise
if some time pass time
passes uh then do something
else so the idea is that um so if Alice
and Bob want to exchange tokens between
two blockchains uh and they kind of know
each other and they know that they want
to do this uh but they don't trust each
other so much that like you could you
would just send Al would just send Bob
tokens on her chain and then kind of
trust that Bob would send her back
tokens on the other chain uh this kind
of forces either both trades to go
through uh or neither so the way it
works is basically Alex will make a
contract that says if the pre-image of
some hash is provided then send money to
Bob uh and she she makes that hash so
she knows the preimage otherwise if some
amount of time passes it'll send the
money back to myself and then Bob will
see this contract and make another
contract on Bob's chain chain B uh and
do use the same hash he do another
pre-image send money to Alice if if that
pre is is provided and otherwise uh
it'll send money back to B so basically
what will happen is if Alex wants a
trade to go through she'll provide the
pre-image of the hash and to take her
funds on B chain and then Bob will
therefore have the pre-image of the hash
and be able to take his funds on Alys
chain so basically without having to
either of the consensus groups know do
kind of any svb proof so the other
consensus groups uh we were were're able
to to do kind of functionality that will
only happen on one if it happens on the
other by using this kind of common
secret uh that if it is provided some
functionality in the contract is
unlocked so this type of
interoperability is called Atomic
interoperability so the other kind of
interoperability is uh is uh the
protocol level interoperability so the
difference is with atomical level
interoperability the things that you're
trying to do is just trying to like
mediate sort of cross Gene interactions
between users so decentralized exchange
is one example or potentially like cross
chain operations where something happens
on this chain only if something happens
on that chain a protocol level interrupt
is where you would have some kind of
Proto some kind of dab or some kind of
protocol that actually on one chain that
actually needs to get services from the
from the other from the other chain as
as a protocol on the whole so one
example just uh one example of that is
uh let's say that you would have some
let's say that you have some kind of you
know you have ethereum on ethereum you
have a contract and then that and that
contract tries is basically is a stable
coin and it tries you know uses some the
sort of contract for difference interest
whatever interest rate target mechanism
to try and keep a keep a dollar value of
one problem is it has no idea what the
exchange rate of a dollar to you know
any to whatever to its volatile coin is
so what it does is first of all would
maintain an internal decentralized
Exchange to figure out the exchange rate
of it its own volatile coin to Ether and
then you need the exchange rate of ether
to the US dollar but because let's but
the situation is let's say that you over
here you have truth coin and Truth coin
just happens to be a decentralized
Oracle because it's the decentralized
Oracle Network and it has you know a
much larger set a much larger set of
users
to to vote so it has more more security
so this little this app over here might
want to ask truth coin what is the price
of what is the price of ether us
and the idea is that this chain needs to
have a way of sort of directly asking
this chain some question so the way that
you generally do that is you would have
you would have the ethereum here
maintain basically a white actually
maintain internally inside the chain a
light client of Truth coin and then in
truth coin you would have in truth coin
you would have some active you know set
some active set set of Voters that are
vote that are just Contin ously voting
on on the question of you know what's
the what's the value of ether and
dollars then if the truth coin
blockchain records some particular
result then a light client protocol of
the a light client Pro the light client
protocol can determine what the result
is so the result would be stored in the
state tree and then basically the the
like line protocol would ask some node
to provide a Merle tree proof of you
know what is the value of a dollar and
uh this and this Merle tree uh ins of
transaction data the like client
protocol would reward whoever provides
the proof and then that's how it would
know what the value of you know ether
ether tover is and then the other thing
that you can do is is that based on
based on Who provided the who set the
transaction or rather based on uh so the
other thing you can do is you can also
peek into the truth coin blockchain and
you can determine who contributed to
this particular vote and then you can
give them ethereum assets inside of
ethereum so you sort of you're just
you're sort of buying service is from
truth coin users inside of ethereum and
you're also and you're getting back this
truthful feed of what the result is and
then given the results the daap would be
able to do whatever it needs to do with
the price of the dollar so that's kind
of an example
of um so that's kind of an example of
subprotocol level interoperability where
you would build in an ethereum contract
an SPV client of some other chain so
that people on ethereum will be able to
know some facts about people on another
chain but if you wanted to have chains
actually share security you would need
to build that in on the protocol level
where not just kind of NOS who know what
these subcontracts are doing would know
what it is but the actual consensus
level protocol would know so the idea uh
with protocol level security sharing is
that uh you would you would build the
consensus of another another chain into
your own Chain's consensus so that you
could for example buy checkpoints buy
time stamps buy uh you you you could use
another chain of services in order
to well so the general idea with sharing
security I think is more is more that
let's say you have 10 chains chain C1
through C10 you know each each one of
those chains has 500 has 500 users and
500 millions of capital the problem is
how do you make each if you just do this
multichain approach by default if you
you know if the whole thing has $5
billion of capital then or if the whole
system has $5 billion of capital then if
you have more applications if you go
from 10 to then each of them is down to
$50 million of capital each of them is
down to $50 million worth of security
and so forth so problem is how do you
have chains that are only processed by a
few that are only processed by
relatively few nodes without having this
problem that each chain only has a small
amount of security right but also so one
thing that we haven't mentioned yet with
one of the benefits of multichain
scaling is that um if a chain is
compromised it won't necessarily affect
other chains as much uh so and you can
provide chains at services on chains at
a given level of security which means
that like lower cost to some users who
don't need as much Security on that
chain uh so what you can't if you want
to provide at a lower cost and still
have high security what you can do is
basically buy security from other chains
um and so and to do that you would
basically need to interoperate your
chain with other chain at the protocol
level and basically have uh kind of like
clients and full clients agree that
they'll use some checkpoint on some
other chain in order to authenticate the
point on the um well the general so
challenge response toy selection we
already we already discussed those in
the context of hypercube um in the
context of of multichain actually well
challenge response in my opinion does
not nearly as go as jury selection we'll
probably talk more about how jury
selection Works in multichain so the
idea is you would have a big a chain and
then on that chain you would have so you
would have this kind of you know
shelling coin consensus thing and you
would have and you have a and you have a
bunch of users that have some that you
know that participate in it and by
participating we basically just mean
having a security deposit on here then
you have some you know some chain X and
that chain X wants to wants to leverage
this little contract for its security
because X isn't big enough by itself so
what it would do is basically this is
this consensus contract it's kind of
like truth coin it's this decentralized
sort of shelling coin massively multi-
shelling coin type Oracle except the
thing that it's voting on is it's voting
on the first oh so what it provides is
it provides a block and the block
provides you know State it's got a state
route it's got
transactions and it's also got a time
stamp and it's and from the transaction
tree you know it's got a meracle tree
here and it's got a Merle tree here so
the question that this thing is voting
on is uh it'll take it'll take the and
of three things number one is the does
the
time does the time stamp on the Block
equal to the actual time number and um
number two is uh number two is that
available
so by is that available do we mean if
you descend from numerical route is is
there data floating around somewhere in
the network corresponding to all of the
all of the leaves of this going all the
way down on the bottom level so the the
idea is that this big this big thing
uses votes on on this statement is did
the block come at the right at the time
that it said that it came at and is and
does the block have that available
and so then what you have is you would
have you would have a trustworthy a
trustworthy source of blocks that have
data available and that came at a
particular time now given that if you
assume that that mechanism is
trustworthy then it turn Z consensus
becomes trivial because your consensus
algorithm basically is that if you
imagine blocks that are at some
particular height your algorithm is a
block at a block at a particular height
is only valid if it is the first block
at if it is the first valid block at
that height so you know if it's over
here and then some new one comes along
this one automatically gets rejected
even if it eventually grows longer and
the way that you defend that is you well
the way that you deter the way you sort
of make this work is that first of all
you know that so the way you determine
the time is by checking the Oracle to
see if in a time stamp M if to see what
the time stamp is the way that you the
way that you determine validity is first
of all if the data is not available then
you say it's invalid now it could be
that the data is available but the block
is invalid but then because the data is
available anyone can audit the block and
anyone can come up with a oral Tre proof
that it's invalid if it if it is invalid
and so this is kind of like full client
security this does like all of the
security needs of a blockchain right one
thing to not is that full clients and
light clients have different amount of
information that they can use to
authenticate different things and so
that you could if you have security for
full clients but not for light clients
then you can do something kind of much
less than this in order to help the like
clients find the authentic chain um
so basically uh one thing that's
important for multi- Chain Solutions in
my view and uh this is kind of like my
vision for ethereum 2.0 is that we would
have like one like client protocol at
least for all of these chains so that a
single light CLI can access services
from all these chains and so for example
if we had uh if if we have some chain
that's kind of secure as far as all the
full clients are concerned but the light
clients can't tell whether some Fork
came later or not because there's no
cryptographic proof of that uh what you
what you could do is basically have the
people on this chain whenever there's a
fork or every so often buy a checkpoint
from a shelling coin game on another
chain which would basically instead of
going on this walk and checking the time
stamp it would it would basically just
ask you know what is the consensus block
a thousand blocks ago because you know
that's kind of longer than the fork
length and so basically it and then and
then like clients who are on who somehow
manag to get on here can find a
checkpoint on this one which you can
then use to authenticate the current
state there so uh in in this kind of
model we can make like a a a tree of
checkpoints so that like clients who
only has one or a handful of checkpoints
could U authenticate the current state
of of other chains um and even though if
those chains are secure for full clients
just by
themselves yes so yes the point is here
is there's a bit of a trade-off between
to what extent you support white clients
and what level of standardization do you
want so the nice thing about this kind
of data availability protocol is that
here you here you actually need to
standardize almost nothing for all these
chains to share security the only thing
that you need to standardize is the
Merle tree protocol because you need you
need to have a way of voting on data
availability everything else is
potentially completely open like this
this might you know this you're not
standardizing whether you're using proof
of work or proof of State you're not
standardizing whether it's uh whether
you're using ghost or or some other
mechanism you're not standardizing any
kind of state transition rule but if he
wants to go into supporting you know
more more sort of like Clin
functionality then you might need to end
up standardizing more things like
checkpoints yeah so for example if uh if
you wanted like kind of ultimate like
client functionality uh what you would
do is have all of the chains be evm and
have the consensus algorithm be embedded
in evm code so that all the like lines
can just use dbm to authenticate the St
State Transitions and to authenticate
kind of anything that they need uh and
basically that makes their code base
smaller than say if they had to
interoperate between chains that have
different protocols right you had a like
client to interoperate you know Bitcoin
and some other chain who P that services
from both it will need more code than if
Bitcoin with VM because then it would
just could kind of use the same code
base to authenticate transitions on both
chains so the more you standardize the
more lifetime friendly you can be um we
already yeah yeah so I guess the so the
last points here are first of all this
idea of checkpointing and so the
question is uh in this multi in in this
multi-chain context can we come up with
some kind of light client protocol that
allows proof of stake clients to still
be secure or to still securely determine
the state of sub the current state of
sub particular chain ideally with a very
low amount of
information yeah um so something else
that we haven't talked about yet is
uh so uh like one one cool idea is uh is
that you might be able to use not the
checkpoint between the chains at the
protocol level uh to to to satisfy the
to do the light client protocol but
actually uh the the interface chain
that's on top actually have we talk
about no so basically if we want to do
atomic interoperability between two
chains so basically those two chains
have the Cher noing uh primitive uh what
you can do is you can make a third
consensus that consensus group that
includes is basically a side chain for
both of those consensus groups and that
can be used to pair up different people
who want to do interoperability using
this tyal imperitive and so one I'm
basically thinking and hoping that we
can use the exchange here to help like
clients figure out uh where to go
because light clients are going to in a
multi-chain context will probably not
keep their tokens on all all of these
chains you keep your tokens on a small
number of chains which are more liquid
more stable and then you kind of sell
them for the tokens that you need in
order to purchase services from some
chain um and you have to go through an
exchange to do that anyway so you need
to authenticate that exchange and so
then you might be able to use that
exchange which isn't even on the
protocol level in order to authenticate
which Fork on these chains to choose as
a light clim um so basically if we build
proo if we build an interoperability
kind of on top using Atomic Atomic uh
inter cability it's less fragile than if
you were to extend one of these
consensuses to include the other one
because if this chain died in this case
it wouldn't affect this chain this chain
doesn't know about this chain it just
knows about some tyan contracts that it
has on itself and it doesn't know what
that what chain that's interoperating
with but if this Chain's consensus was
actually extended to that Chain's
consensus and this chain died this chain
would now have to switch from buying
services from this chain to buying
services from another chain which is
kind of a whole other problem um one way
to handle that that I've kind of thought
of is um if if you don't have contract
creation on kind of evm chain and all
the contracts are in the Genesis block
then two chains with exactly the same
contracts in the Genesis block um are
going to be providing the same service
and so you would be able to switch from
asking a for service from that chain to
another chain that's has the same
contracts um kind of another Paradigm
with this multi- chain stuff is that
instead of having kind of ethereum like
general purpose chains you'd have
ethereum like application specific
chains where basically only some
contracts would be there you wouldn't be
able to create contracts uh and the idea
with the application specific change is
that basically you know if you know that
your application doesn't need any more
interoperability with anything else then
you could have consensus groups just
around those contracts and you don't
need to have the same consensus group do
all these other contracts
um yeah yeah I think that's basically
all that we wanted to discuss so
questions yeah
yes camera sorry hold that thought
thank you for
understand okay so in the very important
special case where the state is just a
bunch of account
balances uh there's a common and very
old idea to uh for scalability
is that instead of atomic uh
transactions which take you know some
value from here and uh credit some other
account you split these transactions
into two into a debit and a credit
transaction and whatever service
needs need needs providing in exchange
for this transfer you make it only
conditional on the debit transaction and
then you settle the the debit
transaction the credit transactions
later when you have time and this way
you can do interoperability between
different chains because on one chain
you if if you compartmentalize by
accounts then you can basically generate
debit transactions as fast as you need
to and
then you can you can do the deits and
the genius one of the genius ideas of
Bitcoin which I think didn't receive as
much attention is that what they did
is that they put together the credit and
the debit but the other way around so
it's not Atomic in the sense that the
something is taken from here and
deposited there but the other way around
that they notic that uh you know you
don't need the you don't need the credit
transaction before you actually want to
spend that amount so what a Bitcoin
transaction actually does is that it
deposits the amount and immediately
takes it
away so uh they don't even have the
explicit balance state so in the Bitcoin
Network you don't have in the state you
don't have the excit balance and I think
that in in ethereum since the balances
are part of this state maybe we should
consider you know splitting up
transactions that modify more than one
variable in particular in case of
transfers they modify two Balan is to to
split them up into two transactions and
make one transaction conditional on the
balance and make the other transaction
condition on the success of the first
transaction so so that that is kind of
what the atomic protocol does it
basically makes sure that one
transaction can only go through if the
other one can go through but it does it
without requiring any information from
one consensus group in the other
consensus group except for the prage of
hash which is kind of more light weight
than having this chain check if some
transaction went through on the other
chain because all you need to know is
whether or not some something the has is
provided oh but that's interactive but
here you can carry the proof with you so
basically if you have a successful
deposit uh a successful uh successful uh
debit on one chain uh if if if it gets
confirmed it's a finite package of
information that you can carry away and
you can present it at that chain and it
gets deposited without so so that's
either a subprotocol level or a protocol
level thing that's more that's more
likely sort of chain scale charting type
approach but you can do that also by
extending consensus in between between
chains yeah you could
but yeah so but it fits more in the sort
of single chain Paradigm yeah so that's
a yeah it's a sharting approach it has I
guess similar similar properties Ty of
sharting approaches the main the main
issue of course is that what if you have
what if you have a de what if you have a
debit somewhere and then you try and use
that as as a proof to generate a credit
twice or or know what if you what if
helpable spending and so forth but
that's a local thing right so if you
want if you want to debit twice using
the same you want to credit twice using
the same debit transactions the you know
the debits of that Target account
they're on that chain so you prevent
double deposits and there you prevent
double
withdrawals instead of you know globally
globally preventing double double spans
you prevent double withdrawals and
double so what if I what if on some
local chain I I make a withdrawal and
then I immediately double span that
withdrawal locally well for sorry we we
haven't even talked about for in so
Forks always basically lead to you
having to wait for interoperability
functionality um because you know
anything can be roll back in a for yeah
um so that's why non having non for
chains of would really help
interoperability Solutions and
blockchain scaling Solutions um one
thing I haven't mentioned yet which I
really like to mention is this idea that
uh one of the things that I find really
helpful for thinking about uh blockchain
scaling is that it's so the client is
serving the user and the client uses
chains to serve the user it's not that
the client is serving the chain and so
uh if a user has a consensus grp
here I think they would prefer to not
have SPV proof so some other consensus
group they're not interested in be
ejected into their
consensus and and that's kind of why I
prefer this idea of um Atomic level kind
of interoperability on top rather than
interoperability in protocol because it
kind of lets the client have more
specific narrow consensus that it's
keeping uh and it it is kind of more
restricted there's less you can do if
you don't have this kind of uh proof of
information about what happened in other
chains
but the Insight is basically that
clients can get SV proofs from both
chains without having to get them from
one chain right um so any any client
that's looking at both chains will know
whether something might thre on the
other chain but that doesn't mean that
you necessarily need to force every
client that's on one chain to know about
what happened on the other chain um so
the the ide's inter interoperability
kind of interface chain that know about
both chains is that those clients that
are watching for both chains can form
their own consensus group in order to
inter operate these two chains without
actually injecting information from the
consensuses into other consensuses which
I kind of regard as inconsiderate unless
it's
necessary um I haven't found many people
to agree with me on that though in
particular in light of the kind of like
you know block stream two-way pegging
stuff which we haven't talked about yet
y um that I is it the side chain
discussion supposed to be later
oh okay
how do you see the upgrade or migration
path from ethereum 1.0 to 2.0
specifically in regards to original
blockchain and so etherum two so from
1.0 to 1.1 first of all 1.1 is just
going to introduce some moderate things
like grou of stake and event trees for
that the approach is to have a
uh is to have a sort of uh mechanism of
of voting on voting on protocol upgrades
so if you so it's not going to be a
minor based that ISM because it's not
because you know it's not it's going to
be in minor interest to keep proof of
work forever but something you know
stakeholder driven where if you have
your coins in a contract that has some a
state at some par A Storage at some
particular key correspond to some
particular value then you're vote
basically voting for you know the
vertical to get upgraded and once
there's some majority in favor of an
upgrade then the idea is that that the
original chain was sort of suicide after
some particular amount of time so all
blocks after block number say 1.3
million will just be invalid and the new
and then clients would have time to
download a new client and that new
client would support the new chain in
some fashion and so that would work for
ethereum going from 1.0 to 1.1 and 2.0
if we're using sharting yes but if we're
using multichain in if we're using
multi-chain intop then ethereum 1.1 will
be etherum 2.0 the only difference
between 1 one and 2.0 will be just a set
of tools for yeah and also kind of like
client protocol or full client protocol
that you uh you know uh Serve All These
Chains or buy services from all these
chains so then basically you know that's
the direction that we're going then
ethereum 2.0 is kind of an interface
layer between all these blockchains kind
of imagine you know if the if the Miss
browser let you buy services from a
whole host of chains uh where most of
those chains are actually application
specific as in you know specific sum out
um rather than being this kind of
general purpose where you kind of put
everything
yes um is the uh chain sharting and the
atomic
um is that Atomic multi- chain um are
are those are those two um they're sort
of competing approaches I would say can
can you could you have both yes you
could could you have the
sh sharded chain and then use this for
yeah a as an interupt thing yes you
could okay
yeah um yeah and I think that that well
would be a good idea because uh if
clients are going to want to keep their
digital Assets in some stable token then
we're probably going to want uh them to
be able do a lot of transactions on the
Chain where they hold their tokens right
if we want if you want to have a a
stable currency across the entire system
the other approach is that we don't
necessarily need the units to be
actually be transferable we just need a
whole bunch of a whole bunch of stable
coins and we need to keep make the
stable coins all target the same
standard and then they'll just be an
exchange it'll be a floating exchange
rate but the floating exchange rate will
just always happen to be
one but then like some we kind of have
have any more stable than those yeah and
so people will tend to keep their money
on those right true yeah because most
like clients don't want to be exposed to
speculating on the success of some do
they just want to be using it uh and so
they can another nice thing about EIC
that we have mention is that you could
pay for a contract call or some
functionality on another chain using
fees on one chain so basically you know
someone would see that you want to call
some contract and they'd be like yeah
okay I want tokens on the chain that
you're paying me on and then they' draun
the contract for you and exchange for
those
tokens so you might not actually need to
change to buy tokens on some daps chain
or if you use the D you could just pay
for it on your chain and have the
contract happen on the da chain which is
kind of
neat can people running CH provid that
service for you basic
they would have to interact on your
chain as um they would just have to the
clients would have to watch it the
consensus wouldn't necessar so only the
clients that are providing that service
would have to watch it basically because
they have to like get the hash value
when they provide it but they have to
want your your your change currency
that's right
yeah or you can even do something more
primitive uh for example if you you you
you form a special contract where as
soon as uh it gets deposited the right
amount then a new chain is started uh
where you know there's no mining you're
you're just using the the deposit and
you can only unlock that contract in the
original chain if all the tokens are
destroyed in the in the first chain in
the small chain and how would that other
CH know that well there's a proof that
you can
and then it have to wait for
confirmations have not it which is
okay so I'm not sure that's necessarily
more primitive this seems a little bit
more
sophisticated well it doesn't require an
exchange this kind of approach is nice
because it's it's also a way of doing
cross chain exchange without ever having
actual basic without ever actually like
having an exchange of different tokens
that are that's across different chains
at the same time is you can expect
onchain exchange to be very efficient
but then interchain interchange stuff
will probably have higher fees but here
it's between the same currency and here
it's the same currency so because the
rate will always be like one the spread
will probably be very
low soorry you said the same same
currency well no so I'm saying you have
a here you have B here right and you
have a here
here exchange between these two is just
onchain so it's very efficient here the
exchange rate is always one so there's
there's an opportunity for like varable
Risk garbage charion same
here another thing you can do though is
just do have security pro and maing here
and basically require people to be
online when they do the exchange so you
can do atomic transactions here rather
than Peg transactions here well you can
do security deposits for everything
can't you yeah you can so uh security
depos are the best because it lets you
make an a really strong because you
can basically say that if you deviate
from it in a detectable way your
security policy goes
away which is NE MH and we'll probably
talk about that during the approv state
panel y
definitely okay anything
else with that said
[Applause]
cool
e e