Layer 2s

Transcript

[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 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