[Music]
um the next panel and the panelist may
come up now vitalic Vlad zamir Gavin
wood Martin beey is a um I the others
have been introduced already as a
ethereum uh researcher and also the core
JavaScript implementer and um finally
Domin Williams please um the founder
co-founder of string and Divinity so um
without further Ado 11:15 and 12 ton and
I'll please take it away gab Gavin
you'll be moderating then yes okay thank
you thank you uh yeah scalability the um
uh the burning issue really at the
moment um one that blockchains um are
often criticized for along with privacy
um so I'll start by getting the guys to
introduce themselves um balic yeah so
um founder and chief scientist of the
ethereum project but regarding
scalability specifically I mean I've
been working
on SK trying to figure out how to scale
ethereum for well over a year alongside
people like yeah of Vlad you know
Dominique and a few others and we've I
think we've generally sort of converged
on a on a fairly small set of set of
strategies that we roughly agree are
going to essentially take us from here
to there that we'll get into too deeply
because that's kind of the purpose of
this hour and you know several future
presentations but I've been in involved
in trying to figure out how to move from
sort of very simple every node processes
every transactions type of proof of work
blockchains the first kind of step step
forward was light client protocols that
have been in ethereum ever you know
pretty much ever since the beginning
since then you know Vlad and I were
talking about things like Hub chains
spoke um Hub and spoke chains
12-dimensional hyper cubes and so I I
wrote a sort of very lar large paper on
the on the topic about six months ago
then I'm probably going to do a bunch of
major major revisions too so that's you
know in general sort of figuring out how
to especi really make make blockchains
and you know using ethereum because it's
you know if you can make ethereum scale
then you can make basically make any
other protocol other protocol scale by
writing it in ethereum code so you know
figuring out figuring out how to
make go towards something that can
actually know process the extremely
large number of trans transactions
that's going to be needed especially if
we're really serious about this whole
sort of moving blockchains beyond
currency and you know talking about esok
and and iot and a node for every every
device type uh type of vision and you
know seeing if we can make it
happen uh hi I'm Martin um I implemented
JavaScript client and um um I enjoyed
hanging out and talking about
scalability uh it's been really fun to
see um the ideas progress from like uh
hyper cubes and tree chains to to where
we are
now I think we're we're headed uh pretty
rapidly we as valal said like the ideas
in space are converging and it's really
exciting to see um yeah cool Dominic
does it work does it work does it work
maybe maybe you want you want I'll try
it yeah hi I'm Dominic um I'm a
entrepreneur and engineer I'm currently
co-founder of uh finex stal string and
uh founder of the definity scalable uh
blockchain project um which is focused
on advancing sort of blockchain science
uh with a particular focus on
distributed virtual machines the kind
ethereum is um before that I um uh
created a game a computer game back in
the UK and then moved to us about 3
years ago um the definity project itself
came out of a now defunct cryptocurrency
uh project called Pebble which was
looking at Price stable uh scalable
cryptocurrencies uh back then with a
focus on
micropayments um oh there we go I've
been working on proof uh proof stake
obviously for like a year and I've also
been working on scaling um a little a
little bit before I started working on
proof of stake I was working on like
proof of work only scaling and I still
remember my first idea it's called proof
of proof of work where you would have
like a concise proof there was a lot of
proof of work somewhere else um and
since then we've yeah we've come a long
way uh we had like had a period of time
where I really thought that um the
correct way to scale would be to have a
lot of blockchains and find a way to
that they can reinforce each other's
security by interoperating after the
fact called like the multi-chain
approach and ever since then we've been
moving more and more towards these kind
of uh scaling solutions that provide a
singal development environment rather
than uh give having developers deal with
different chains
explicitly um and I think that you know
that's one of the key design principles
that we have in our current
scaling um
approach cool um so FL one of the things
you've been working on recently is
indeed Casper so the new people have
worked States what do you see as being
um uh important um in terms of
scalability with the work that you've
been doing on
this sure so Casper being sorry Casper
being a single blockchain doesn't
directly solve the scaling problem um
but there are a couple of things that
are in Casper that are necessary for
scaling Solutions one of which is the
um production of evidence and the idea
that we can um go and punish particular
nodes for producing invalid blocks um
cuz it a scaling solution where not
everyone processes every block there
could be a small Shard or group of
validators who produces an invalid block
and we need to go
and reprimand them somehow from
producing this block and we have this in
Casper and it's a necessary part of any
scaling solution because um one of the
key problems any scaling solution is how
do we deal with invalid
transitions cool another kind of
important thing for blockchain scaling
more generally is that um it's really
important that our scaling solution is
kind of economically efficient uh and
that it it shouldn't be that we require
even more electricity consumption than
Bitcoin takes today to scale Bitcoin up
to like more transactions a second uh
and proof State kind of represents
a an economic Improvement in terms of um
the cost of processing
transactions cool um Dominic you've been
working on Pebble uh
recently well yeah pebble's kind of Def
definity now so
um yeah um definity addresses um you
know the scalability challenge and um
interesting you know vad just mentioned
U you know how he started with lots of
separate chains and uh having developers
in interact with lots of chains that's
kind of how Pebble started out um we had
consensus groups and um when you know a
transaction would send for example
currency from one an account managed by
one consensus group to another consensus
group um it happened L was propagated
lazily and and the recipient the
receiving consensus group would try and
validate the other consensus group and I
think um it's a sort of necessary
process to go to but
you start off trying to address the
problem like that and you realize that
the whole system becomes very difficult
to reason about because um you
know unfortunately if if one of these
chains or one of these consensus groups
becomes corrupted potentially it can
export bad State transition bad currency
bad data or whatever it is to the to the
other
groups um and so you realize that that
slightly naive approach to scaling
doesn't work and that was one of the
reasons that Pebble was was never
released because I wasn't satisfied with
that so um you know that's one of the
fundamental challenges and the approach
that we take is to um I was glad to hear
compositionality mentioned earlier in
the previous talk um to first of all
separate the different kinds of um
processing that needs to be done in in
in a kind of distributed crypto Ledger
and so when we look at a crypto Ledger
we see three different requirements we
see global consensus you know Global
agreement on what the State of the State
exactly is we see
validation um which is the validation of
transitions which is distinct by the way
to consensus right because you can agree
on invalid state right you can have
everybody in the network agree this is
the state but that state could have been
um updated in an invalid way right so
you you have a validation layer and then
finally you have a storage layer which
stores the state so the storage layer um
will obviously need to be sharded in the
same way that you'd Shard a large
website for example um and
that's more of a static thing because
you can't move large amounts of storage
around so the problem becomes you know
if your bottom layer is sharded your
storage layer is sharded how do you um
stop one of these shards become
corrupted in some way and then exporting
bad data to the other shards so you
actually have to have a global
validation there above the
storage and scaling that validation
there
is one of the key challenges but there
are ways of doing it and then once you
validated data you can reach agreement
on it in in the consensus
L definitely f a thought later um Martin
you've been working on the uh ethereum
JavaScript client uh mostly would you
like to give some thoughts about um how
that might be made into some scalable uh
uh system yeah um I'm I'm not really
sure if the the JavaScript client
directly has much to add to scalability
but um I I do want to say like uh to
give some intuition about what we're
doing with scalability or want to do um
is that right now uh we have a universe
and every actor in the universe uh uh
every interaction in this universe takes
the same amount of
time um and is so you can think of it
everybody is the same distance away uh
and this works fine when we have like a
little universe but um if we want to
have a really big universe we need to
Overlay some sort of um spatial doesn't
have to be real space but we have to uh
have we have to add distances if you
will um it's sort of a higher level way
of just thinking about um what what we
want to do with scalability so what does
that mean like right now when one
contract calls another contract um it's
always a synchronous operation right and
if we have you know different times
maybe that
um contracts could take because like if
one contract calls something from
further away it should take longer so um
thinking about it from this way sort of
interesting it means you know the
necessarily there will be an
asynchronous environment in which
contracts might call and of course these
aren't fully flush out ideas but um sort
of thinking about the properties that
scalability we have um and then mapping
it onto our current system is
interesting I think
um one other uh one other thing like
Dominic said like separating different
layers uh having um one layer that does
uh State Transitions and then another
global uh a global layer that comes to
consensus on what all the state
transitions is seems like like pretty
good path forward um so yeah cool um
vitalic now at the moment we have a
system that has a number of properties
yes um Martin um mentioned one with um
synchronous calls between contracts um
going forward into a um a viable
scalable solution mhm um which of these
properties do you expect to see um being
relaxed right so I think there is a few
properties that you know blockchains
right now provide whether it was an
intentional design goal or you know
accidentally so one is this concept of
synchronous completely Global State
transitions so an ethereum contracts can
theoretically call any other other
ethereum contract the specific ethereum
contracts that it calls can be decided
at runtime those contracts might call
other contracts
essentially you theoretically have like
pretty much no limits on what the
resulting state is after one one
transaction got applied except for you
know the implied kind of restriction
that comes from the gas limit so that
another key another key point is that
absolutely every transaction absolutely
every account has the same level of
security which be which is that you know
in order to reverse the transaction or
in order to censor some particular
application you needs to perform a 51 %
attack on the entire system you know we
have there's the question of exactly
what exactly what kind of properties the
blockchain provides there's the block
time so blocks come come every 17
seconds approximately on Frontier so out
of those the question of which ones you
want to sacrifice I think really depends
on your application so for example you
know if you're talking about a currency
application and we have some case where
you know ethereum let's say has mass
adoption and I have some you know
ethereum based based tokens such as you
know let's say you know digs Global has
their gold gold coin on ethereum out by
then and I wants to pay for a coffee
using $2 of gold then that transaction
does not need to necessarily have you
know an entire $20 million of security
backing it so one route that you could
take is you could try to relax security
and basically say you p pay for security
and you know your transactions can be as
cheap as they want but then their
security is also going to be
lower now of course one other category
of application where reducing security
is o is okay right so the well or rather
the other property that blockchains
provide is this the existence of this
concept of global of global state that
everyone completely agrees on so one
important category of applications as
proof of existence so basically this
idea of using the blockchain as a
timestamping tool and and basically you
know you said you publish a data a piece
of data a bunch of people's pieces of
data get aggregated into a Merkel tree
the root of that Merkel tree goes into a
block header and you have this kind of
proof that's kind of permanently you
know etched into existence and you can
use this spel Branch as a receipt to
sort of prove to anyone else forever
that this particular object exists at
this particular time that's something
that's actually much easier to scale
than either currency systems or like
folding we smart contract platforms and
so the way you do that is basically you
know by sacrificing the idea that even
every node needs to receive all needs to
receive or be able to receive all the
data sacrifice the idea that you needs
to worry about double spends so or you
know that two people creating the same
record at the same time is a
problem another category of things
that's worth um com that's worth
thinking of compromising on a synchrony
so in general you know with some with a
theorum right now any contracts can
theoretically make a huge set of changes
and therefore if you get two
transactions right now it's virtually
impossible to process them in parallel
in the general case because
theoretically they might end up
affecting the same account and the way
that they affect that same account might
be non-c communative and you know you
can't necessarily sort of detach those
cases beforehand because of various
corollaries to the halting problem so
one approach that you could take is you
could say that contracts in some cases
so let's say if you split up the space
into into you know we call shards then
contracts that call contracts that are
sort of physically close to them by some
metrics they can do that synchronously
but if he wants to call some call a
contract that's say very far away in
this metrick then basically the concept
of the event of making a function call
and the event of processing that
function call in a separate chard might
needs to be sort of separated from each
other in time and that's something I'm
actually going to be talking about quite
a bit more this afternoon so I think
depending on depending on which
application you know which one of which
one of those you you want to compromise
on is you know it might be different the
challenge with ethereum of course is
that you know we are trying to create
this sort of decentralization for
dummies kind of platform and we wants to
sort of protect developers as much as
possible from having to even think about
these issues so I think and a really
important question for us all to be you
know trying to figure out is what are
the nicest simplest and sort of the
developer friendliest possible
abstractions that we can give developers
in order to let them sort of choose what
tra what trade-offs they want among the
different choices you know to the to the
extent that they have to without and at
the same time still make development as
easy and intuitive as
possible thanks um Martin Could you um
JavaScript is nice as a language in that
it gives you an awful lot lot of
latitude with what paradigms you can use
um can you imagine any um alterations to
contract programming perhaps even the
virtual machine that would
facilitate um paradigms allowing you to
program on a on a system that vitalic
talking about oh yeah definitely yeah
definitely um um asynchronicity is very
important in JavaScript um it was invi
designed to run in single event Loop and
you don't want to you don't want to stop
that event Loop um so if you don't
program asynchronously in JavaScript
it's uh you get really poor
performance
um and I I don't think that this
necessarily holds just for JavaScript
but uh the the asynchronous uh design
patterns uh I think are very relevant
here so I would imagine if we had from
from a developer's point of view if
you're a contract developer
um and and we had an asynchronous a
development when you're calling like to
uh some part of the uh State that's
really really far away and it's going to
take a while it would be sort of like
getting a promise back in JavaScript or
a call back you know it it could be it
could work the same way so yeah cool um
when we tend to think about um scalable
Solutions um normally in some sense at
least they revolve around not all nodes
processing all transactions or storing
all data or even being aware of of all
data this um brings into the Limelight a
problem uh known as data availability or
proof of availability whereby nodes that
are not privy to um the transactions
that some other nodes have have
validated um must ultimately work with
um work with those those
transactions um could you um give some
proposals
vad um on how to um address data
availability in general uh yeah I think
this is still an open question kind of
but uh one example in Vlad has a a
scheme for proof of existence right uh
so we have this data is all merized
um so we one one simple scheme right to
give you maybe some intuition and how
how we can build more complicated and uh
maybe uh better schemes but uh we have
all this data merized so we can query
the noes that are supposed to be storing
the state uh and ask them for random
keys and make sure that we get back a
correct proof right mle proof uh and if
we don't we could punish them and maybe
a slasher that uh um slasher style uh
thing when we take their deposit whatnot
um so I think that's sort of like the
core of how uh um most data availability
um
schemes uh work okay another sorry one
second it'll turn on in a second okay um
another another thing that's important
for data availability checks is uh the
idea of escalation
where uh if some nodes claim the data is
available and produce proofs and other
nodes claim that oh you know I actually
can't download this data um that's why I
can't produce proofs um so the noes who
can't can't download the data would
basically Sound the Alarm causing more
nodes to attempt to download the data
and then if there's still disagreement
about whether the data is available we
can escalate further uh and until we get
to basically all or a very very large
portion of the nodes trying to download
this block which may or may not be
actually actually have been published
Beyond like some attackers nodes um and
and then and then we would have to
resolve in the end with what we call
subjectivity where basically NOS go with
whether or not they personally were able
to access that block as opposed to uh
with the result of voting because voting
alone can't really resolve this question
uh in an environment where an an
adversary might control very large
proportion of of the notes who's voting
are the validators voting yeah the
validators are basically saying whether
or not they're able to uh download this
block which some validators are claiming
is not available right so the important
part there is like uh the the people
voting have stake so like it's not just
anyone um but also sort of a fun a fun
uh attribute to this protocol is that
like the if you see that some dad bad
data uh if you see that someone's making
a bad claim and you counter it uh you
would get some reward so like this all
has
incentives um to work out hopefully
right so one particularly useful tool in
the um in the in pursuing scalability um
seems to be a cryptographically pseudo
random sampling in order to select some
nodes um ahead of time to determine
um uh what precise what precise role
they will play in the uh in the
consensus algorithm um Dominic would you
like to comment on that yeah sure so um
I I think um we're going to see that
Randomness is really the tool that s
solves all of these big uh scalability
um challenges um so uh
at least in the systems I've been
playing with uh you have a top level
chain that not only records consensus
but also generates a kind of random
heartbeat and that random heartbeat can
be used to drive the organization of The
Wider Network right it turns out that's
very powerful so just circling back to
this validation problem there was U
constructs um came up with a year ago
called validation Tas which is very
similar to the um
system these guys have been working with
and uh it works something like this um
let's say you've got a storage State
Storage shod and it has a transaction
come in that transitions that state it
needs to be validated and that Val that
transition will be mapped to what's
known as a a validation tar and a
validation tar is bit like a kind of
chain that grows each successive level
on it is built by a randomly
selected set of uh nodes and this can be
a very small set of nodes for example
five you know five five processes in the
in the network and those five processes
will be past the transaction and any
other transactions map to that Tower
they have to build a level that
validates that those transitions are
okay but in addition to that they also
have to validate some number of levels
below them so for example let's say
they have to validate nine levels
beneath them okay and let's say that
data has passed through the validation
tab when it's being validated by 10
different levels now the trick is that
we say those those nodes that have been
selected to build a new level in the uh
validation Tower become
inactive okay until the level that
they've created has been buried this
number deep okay so they they become
economically inactive so if an adversary
controlled that group and created a bad
level that validated data that nobody
else would validate he could become
stuck now of course the adversary would
like you know to be able to have you
know his nod selected to build let's say
the next 10 levels right but of course
the selection of the nodes that build
each level right
is determined by the random heartbeat
and this Tower grows in lock step with
the random heartbeat and if a level is
ever ever missed then the validation
required of all remaining levels um that
aren't valid validated resets to the
full depth so what does this give us so
for example in in the Bitcoin blockchain
um we have I think 10 approximately
10,000 nodes and every single node is
supposed to they don't actually but
they're supposed to validate every
single transaction that makes it into
the blockchain that's a very sort of
naive and inefficient approach but we
might imagine with something like
validation towers that we we could get
the same level of security with 50 nodes
right let's say that you know we have
five nodes that build each successive
level right and you need to get a
transaction buried 10 levels deep right
and the reason for this is that the the
probability of the adversary
having five of their own nodes selected
from some big universe of nodes in this
case we're saying 10 times in a row is
vanishingly small right and every single
time the
adversary hopes this is going to happen
and builds a bad level which perhaps
validates some silly transaction that
pays him you know trillion dollars or
something um every time he tries this of
course he's having to spend money
because his nodes become inactive until
they're buried 10 levels deep and it's
never going to happen so the um
resources of the adversary will quickly
become exhausted and we can get the same
kind of security from just these 50
nodes that that Bitcoin can get from say
10,000 nodes and so I think that that's
um as a technique it's an interesting
one it's um but it kind of illustrates
how a lot of these problems that seem
very intract intractable can be solved
using random right so I think the
generation of pure Randomness that an
adversary can't manipulate or predict is
going to be very important and luckily
there are ways of doing this um using
adaptations of uh certain kinds of uh
threshold signature um
techniques and in fact actually anyways
proof of work is a kind of Randomness
it's not ideal because it's too easily
manipulated but you
know when you create that you find that
Nots that gives you the leading zeros
and your proof of work you know the
resulting hash is pretty random so in
principle you could even do this with a
with a proof of work you know top level
proof of work blockchain it's not not
ideal but in principle you could even
use that the randomness generated by
just a proof of work blockchain to to
drive validation
tows cool
great way back when probably about 15
months ago we were talking about a
notion of um ethereum 1 1.5 which would
would go halfway towards scalability if
you remember um to some degree it was
built around the notion of having
separate chains that linked back to the
main chain and from which um proofs
could be given that transactions
happened or that a state was in a
particular
State um would you like to comment on on
and explore the notion of this ethereum
1.5 idea still and uh no not
really you're done with that now right
I mean the basic notion is I well
there's a bunch of things that were
called e theorum 1.5 but one of them is
this Hub and spoke chain notion where
basically you would have a hub chain and
you'd have many spoke chains that you
know theoretically could be sort of can
rely on the or benefit from The Hub
Chain's Security in some sense so the
particular thing that I that I come up
with was a sort of symmetrical merge
mining technique where basically every
minor would this was you know back in
the proof of at the the time we were
focus focusing on proof of work so every
minor would make choose a hub a Spoke
index to make a block on and then they
they would make a block and then that
block would point to both the previous
block on that spoke and the previous
Block in general so you know basically
and that block would count as a block on
the spoke and as a block on the Hub at
the same time and so the theory is that
you or was that you could have the
system where transactions that sort of
happen within a particular spoke could
potentially be extremely cheap because
there aren't too many too many miners
valid Pro actually processing them but
and you know the theory is that every
minor would be kind of a full client on
their kind of home spoke but they'd be a
light client on every other spoke so
they'd still have some degree of access
to it and but at the same time you know
if you wanted to have interoperability
between spokes you could but would go
through the
Hub could you see that model um scaling
indefinitely through compositionality a
sort of Hub and spoke spoke is a hub as
well as a spoke and has further spokes
down maybe but I think we also needs to
kind of think more more rigorously about
exactly how it is all these systems are
secured because the problem with
scalability is that there are there are
two there are like so many ways to do
things that look like you're solving
scalability but where you're actually
sacrificing a fundamental security
property so one example is you know
right now the sort of de facto model of
cryptocurrency scalability is that well
we have M we have hundreds of altcoins
and you know if Bitcoin hits its limit
and if you know the politics don't get
figured out and limit doesn't get raised
then people can just sort of move over
and do stuff on Litecoin and Dogecoin
instead the problem with actually sort
of
institutionalizing that as the skill
ability Paradigm is of course if you
have a th chains then each chain is a
thousand times weaker and particularly
if he wants to maintain the property of
having a currency that exists on
multiple shards then one of these shards
could sort of get overwhelmed and then
as Dominique say it could start sort of
exporting bad data to the other shards
so that's one bad way of solving
scalability another bad way of solving
scalability is is basically you know
merge mining so you know merge mining is
definitely a you know a decent thing
that has a lot of uses that was used to
and it still is used to secure name coin
but the problem with using it for
scalability is that right basically
let's imagine that we have a world where
people wants to have basically a
gigabyte worth of transactions every
block one approach is well let's just
bump up the block size limit to a
gigabyte done every every full node has
to process a gigaby every 10 minutes
another approach is to say well okay
we're going to do we're going to merge m
a thousand side chains and each of the
side chains is going to have a block
limit of a megabyte but then the problem
is that for a side chain to be secure it
has to be merg mines basically by you
know almost all of the miners and so
almost all of the miners still basically
have to process a gigabyte every block
so that is one of those solutions that
sort of doesn't actually solve the
problem so the challenge is now of
course you know side chains definitely
are you know they do have value but
they're more but you know even by
blockchain themselves I think they've
always been marketed from the start as a
functionality solution and not a
scalability solution so for scalability
we have to figure out exactly how the
validation is going to work you know I
think the solution definitely is going
to involve some kind
of global validation involving random
selections But ultimately actually I do
think this sort of compositional
recursive approach is the way to go and
if you're also if you're doing a global
composition compositional recursion then
the number of spokes per Hub you know
just might as well be the computer
scientist favorite number of two
so cool
yeah um so kind of tying some of this
discussion back to my presentation about
like making these systems work in a
context where a majority of nodes might
be rational and colluding
um it's really important to have
Randomness that uh has it like one of
these security models where any one or
any small number I preferably one Noe
who isn't colluding with everyone else
could cause uh the entropy to be
nonpredictable um and there is a there
is a randow project that is working on
one of these systems where everyone who
is part of the random number generator
has to place a security deposit and
reveal a commitment and if they don't
reveal then they lose their deposit but
if but any one of them could stop uh
everyone else from secretly sharing
their commitments in order to produce
randomness so uh and and additionally
for the um validation thing ALS also if
you know a large percentage of the nodes
are are are colluding um then this kind
of escalation and uh subjectivity become
really important parts of the
solution um one thing though that that
I'm hoping that we'd talk about a little
bit more uh is the idea of um to to what
extent can we provide a general purpose
platform that we can reason about how
the shards communicate to each other by
requiring developers to kind of uh add
give us more information about what
their contracts will do at when they
deploy them MH sure um Martin you like
to comment on
that yeah I guess there's several
methods of uh doing that and I think
you're probably thinking of like more
formal proof like uh seeing like what
contracts is going to call out to and
like doing type matching is that what
you're thinking right yeah
um I'm not I'm not convinced yet that's
that's the way to go because uh there
there's uh if you have a general purpose
uh turning complete virtual machine then
you don't at some point you don't know
what calls it can make and uh should
just be built into the the protocol that
uh the be able to handle that even
though that there will be some syn
asynchronicity and it will take longer
but those will be have to be things you
can program in at a lower level sure but
I mean um if if you if if a developer is
willing to tell us okay you know this is
a key value store that acts in this way
then we will be able to um better manage
the different like shards of of that
particular application because we'll
have information about uh you know the
fact that transactions are commutative
for example if they don't affect the
same key right right so yeah sure we we
we can imagine your situation right
where we have lots of transactions that
are totally communative right for
Pacific um uh Pacific contracts uh yeah
that's that's a really interesting
concept um yeah so that' be cool but
like don't you think you probably should
start from like the general View and
then add the optimization later or do
you think that that like you can start
from the view where um we have this
metadata if you will on the the
contracts well I mean I kind of think
that um there there's some extent to
which it's like a fundamental problem
that you can have a contract call every
other contract and that the other if
another contract relies on the data they
get from this one this one contract um
and then if you're using asynchronous
calls and that that call was created
from an invalid block
and then that block later gets reverted
uh the question of whether or not that
invalid data is like used by these other
these other uh these other contracts uh
you know may make may make application
developers developers suffer more than
if they just because then they have to
like deal with locking as opposed to and
like monitoring other shs as opposed to
just kind of having more restrictions on
what you can program right so there
there's two separate issues there though
one one there is like um uh containment
right so if some so you're saying
assuming a valid um State transition
gets through on another state or some
some state right um and then like how do
we revert that right and then have AEL
has the the what is it called the cone
of um
um the the cone you have to revert if a
bad depc yeah the dependency cone well I
used to have the dependency cone concept
I think over time I've come to realize
that the dependency cone is going to hit
100% of the stage so quickly you might
as well not even think about it yeah um
so right so if you you had a like a bad
State transition and you had to revert
anyways that would be I mean yet so I
don't know if we we need to consider the
first part of that yeah I mean this I
think this depends also on sort of what
your underlying security model is
because if all of these shards are
ultimately sort of under one header
chain that you still have a global
sequencing model so you can still know
that if one thing gets reverted then
everything after will get
reverted so to what extent do you think
we will be able to keep the notion of
absolute truth which is to say a global
lock step State um fully
objective um going into the future and
to what degree do you think we may have
to fall back on uh sort of this notion
of uh a relative Truth uh depending
depending on where precisely in the
system you happen to be by asynchronous
or by global absolute state are kind of
are are sort of morkal receipts of
asynchronous operations in progress
allowed to be part of the state um in
principle yes if if so I think that's
fine we can we can still have Global
truth and we aren't we already sort of
like at a a situation where we don't
have immediate Global Truth uh the
global truth becomes uh more final uh
after after time goes by so it's already
we start off with like possibly vague
Global truth and we get some more blocks
and then we have a more solid version of
global truth so um
yeah um I I kind of I kind of think that
um we should definitely explore the
possibility that using stronger type
information we can have um concurrent
execution of transactions where we don't
actually have a global consensus on the
order of transactions because we see
that we don't need it because of
something about the particular
applications that were that were that
are deployed on the platform okay let's
explore that so um would you see the uh
inherent linearity of the blockchain as
it's as we have it so far to be uh
something that can be uh discarded going
forward um I think that uh it it with
like if if you're if your application is
like so general purpose that it can
affect any part of itself then there's
like uh you can't really get away from a
linear model but if you have more
information about what the application
does and and and the
application so for some applications we
can definitely get away from the linear
model from some applications we can't
and so we stand to benefit on a scaling
side if we can
identify how strictly transactions need
to be ordered from a about two
application but by you know from
information given by that
application so in principle um sharding
the uh Shing the the state and allowing
different sets of nodes to process each
different part of the state in
parallel um would relax the notion of a
this inherent sequential
larity um to what extent do you think
that can be taken um in this this sort
of fractaline notion that uh that lucus
presented earlier well I mean so um if
you have one application across many
shards and that application requires a
strict ordering then it will need to
kind of Lock and wait for messages
across different shards anyways so just
the fact that we have
shards uh doesn't mean that for a
particular application we can deal with
concurrency it has CU like certain
different applications will
like can inherently uh allow for more or
less ordering of transactions that
affect their state um and yeah I think
multi- Shard applications are something
that we're going to need to to think
kind of long and hard about um because
you know in as far as an application is
all within one Shard it's the story is
pretty clear between
shards the application developer might
have to do more
work to deal with the logic there if the
transactions really aren't uh globally
ordered and affect the state uh
I mean if if the sh so basically The
Shard will have to be big enough to
include all of that application state if
that application needs a global order
and if we process transactions
concurrently between
inss hope that makes sense Dominic any
comments yes so I I think even with uh
is that working yeah even even with um
uh you know sharded architecture there
still has to be a single linear record
of you know overall State transition
um so you know the network scalable
network is probably best thought of some
some kind of pyramid you know and the
top of the pyramid is the global chain
and the uh at the bottom of the pyramid
the the storage shards um the
transactions themselves will have to be
asynchronous which means that you know
effectively some kind of event passing
Paradigm
um very simple example might be with
just a simple cryptocurrency that you
know if you've got two wallets um one is
on Shard a one is on Shard B the wallet
on Shard a wants to send uh some money
to the wallet on Shard B um a
transaction is created um that that
really um consists of two parts two
parts you know a debit and a credit and
first of all the debit part of the
transaction is submitted on Shard a
that's validated and only one it's
validated is the credit
uh part of the transaction actually
submitted on Shard b
um
but you know even though there's a
there's a there's a process by which uh
you know a smart contract might send
some message to another smart contract
well that the creation of that message
has to be
validated while it's being validated
that message is in some kind of QE um
the Q itself is part of the state right
so that can be validated too so
um you know there is some ordering not
only of the state transitions but also
the the message pass which is a formal
State transition
anyway so I'd like a quick poll um to do
we think that for ethereum
2.0 scalable ethereum we will be able to
retain um our exact same execution
environment um I the property that I'd
like to achieve is that first of all I
do think that ABS you know simultaneous
synchrony and very very high scalability
is
not is not achievable for you know
fairly simple computer science theoretic
theoretic reasons but the the properties
that I do want to keep are number one if
you do not want properties that do not
exist right now then you should not lose
anything that exists right now so that b
so one example of that is that
applications that are within the same
Shard should maintain the exact same
development model as much as possible um
another one and another one is ideally
you you know there try to make try to
sort of every time there is a
fundamental tradeoff basically you know
I think you good design should instead
of making the trade-off for everyone
sort of presents the tradeoff so for ex
one possibility for example would be to
come up with a mechanism that offers a
choice between let's say offers a
trade-off between transaction fees for
example and the maximum size of uh of
the sort of radius within which you can
do you can do synchronous operations so
I think you know with the it's not so
much and a like 100% of a and 100% of B
are probably probably not possible but
the choice between 100% of a and 20% of
B and 20% of a and 100 % of a and and a
whole bunch of stuff in between I think
completely
viable yeah so
property um I still a little jaet leged
um so um yeah properties U I pretty much
agree with v right there um like we want
to keep the same environment programmers
have um contract developers but we needs
to uh add this um property or notion of
uh talking
somewhere far away and how how do we
inter how do we inject that like it
can't be totally uh synchronous or we
have to sacrifice something so I like
the property of being asynchronous uh
and
yeah
much um yeah my view on it is I think
the um I think the sort of transition to
theorum to will take longer than people
expect just because uh the protocols
become much more complex when you uh
start dealing with uh scale out systems
um having said that you know I think
ethereum surprised everyone me included
with the you know speed of its
implementation and the fact that it's
been so stable in
production um so yeah way to be
pleasantly
surprised yeah um so I think that the we
we're still in a stage where the the
most that we could imagine that we can
get out of a scaling solution is is is
is growing like we can imagine scaling
Solutions today that offer us more
guarantees than the ones that we than
like the the kind of first order scaling
Solutions like the one in metallic paper
which by the way I recommend everyone
read I think it's super compelling
um so the so for ethereum 2.0 I think we
can have a lot of the same kind of
semantics for the developers and I think
that there will be like make there could
potentially be relatively small changes
that will only affect application ations
that span between
shards um but I think that in the long
run we shouldn't should not be bound by
backwards compatibility uh if it means
sacrificing uh scalability and general
purpos of scaling solutions for example
uh the goal of providing transitions at
different levels of security uh is one
that cannot be done without adding um
semantics to the to the to the pro
development environment you because
developers will need to say whether this
needs to happen at a low level security
or whether it needs to happen at a high
level
security so it seems that we've um uh
We've identified three potential sort of
points that may need to be sacrificed in
some sense on the one hand there's
synchronicity then there's the um the
fees that need to be paid and then
there's um the speed at which the
transaction actually gets fully executed
within the uh within the state
transition system um do you think that
we'll be able to work toward a model
whereby the the uh the programmer is
able to trade these three off against
each other as they choose or do you
think by and large it's going to have to
be set up front that's that's definitely
at least my
goal um to what extent that to what
extent that's going to be possible I
mean I think it especially between es
between asynchrony and fees at Le I'm
I'm fairly confident
I haven't spent too much time thinking
about the idea of kind of letting
developers choose security levels mainly
because I think up until now like like
myself and all of us have been working
in this model where sort of it's assumed
that everything is going to work and
allowing even one fault is sort of cons
considered Unthinkable and of course the
reason is that if you don't have that
model and once you get to the point
where the network is supposed to survive
supposed to survive successful attacks
then you know Apple app ation all have
to start worrying about well what if
someone you know moves moves a trillion
ether into this account or prints a
trilon ether out of this account here
then you have contagion problems and
then you know different applications
have to start dealing with this so like
there are I think possibilities like one
one idea that I've had is this idea of
having kind of sort of islands of
decreasing of decreasing security where
things that are from that are sort of in
higher security levels can filter down
but you can't filter up at least within
one transaction or you know without some
sort of particularly special set of
rules but that's that I think is going
to take more work particularly because
outside outside of the decentralized
cryptoeconomic context people aren't as
used to the idea that well operations
can just randomly fail like that's
almost kind of a almost a biologist way
of think of thinking about things to
some
degree
um yeah I think well so one one
interesting thing with uh asynchronicity
is there you probably could also pretend
to have synchronous calls by um pushing
all your work up front and like
downloading forcing the validator to
like download act as L and Kay and
download like other other substate that
didn't have and didn't run it but um so
you could I
suppose uh make it look like it running
um synchronous but it would actually
just take the whole transaction would
just take longer so um that's one
trade-off uh the yeah I hadn't really
thought about the different levels of
security um and then um yeah taking
longer for the uh the uh State
transition well that yeah I think that
uh I don't think the programmers would
have access to the state transition so
um I'm not not for sure how that that
would work but
yeah yeah so this um the the
configurable validation um is a really
important area um I think that with with
scalable blockchains the cost per uh
transaction becomes very low the main
reason you'd want to reduce the number
of levels of validation is for reduced
latency okay um there are some
complexities um one of them is that when
you pay a you know if every transaction
pays a fee right every transaction
involves a currency transfer so you
can't really easily reduce the
validation on it because um you know
even though the transaction fee itself
might be you know 1,000th of a cent it
could be like whoops I'm the minor and
I've just you know credited my account
by ,000 right so uh one one way of
addressing that is to have probabilistic
fees so you know um you only pay your
fee one every hundred times right so
your fee is 100 times what it would be
but you only pay it one every hundred
times right so then if you have reduced
uh then if the application developer
specifies a lower level of
validation um you know 99 times out of
100 uh they're not going to pay a
transaction fee and therefore it's they
they get that reduced level of
validation and they get the low L
latency but one time out of a 100
uh they will pay the transaction fee and
and consequently actually that
transaction will run at the full level
of validation um but you know that's a
kind of simple way of of uh allowing the
application developer to you know for
example get the reduced latency 99 times
out of
100 it's not perfect but it seems to
work so just kind of quickly um I think
that we can isolate shards from each
other uh and and and have low security
uh transitions basically you can think
of it as kind of like a two-way Peg
where there's only so many tokens that
are in that Shard and like the the other
shards know how how how many tokens are
in there and if something goes wrong
then the loss is bounded and we don't
need to escalate to deal with it we can
just accept invalid transitions there by
kind of isolating the rest of the system
from the failure of that Shard but
anyways our our time is
up