Scalable blockchains as data layers | Vitalik Buterin

[Music] okay so uh today i will be talking about a a new kind of layer two construction so something that's not quite the same thing as a as a layer through for scalability like state channels and plasma but also not really the same thing as existing layer ones we're kind of something in between that basically uses blockchains as a place to store data but does not actually do one computational chain and instead it does computation using things like these darks and other kinds of things and i would and the interesting thing about this is that once uh blockchains start becoming more scalable and once uh ethereum 2.0 and serenity reach a certain point it actually makes sense to make these kinds of applications that use blockchains for data but not for computation in a lot of cases so the idea of using blockchains as data layers actually has a long history so this is a pro a protocol that i actually i worked for for about three weeks back in 2013 it's called master point and like at the time this was considered really innovative right so the idea is that they that mastercoin created a what i called a meta protocol on top of the bitcoin blockchain so then sending a transaction in the mastercoin protocol is sending a bitcoin transaction the transaction goes in the bitcoin blockchain it gets verified by bitcoin miners he accepts the mastercoin protocol defines a completely different set of rules for interpreting what these transactions mean so it uses the bitcoin blockchain as a data store but not as a as what we call a state execution object now if you have the bitcoin blockchain and you have a masterpoint node you can compute the master code the master coin and the stage pretty easily you basically start with the genesis state and then you would have some program that we call the state transition function and you start with the genesis data and then you just apply every single bitcoin transaction in order most of the bitcoin transactions don't have the kind of mastical and flag on them so they'll just do nothing but the ones that do have the master going flag on that will be interpreted and they can do things kind of inside of the context of the mastercoin protocol that the bitcoin protocol just completely ignores so with inside of this masterpoint protocol it defines msc the currency you can do financial transactions you can do a very primitive version of smart contracts and a lot of other things right so the reason now what's primitive about it right so first of all the master coin protocol is not lifeline friendly so if you want to learn what the current state of the master point system is then you basically have to actually have bitcoin blockchain have the master coin know code and process every single bitcoin transaction with the master coin flag attached to it in sequence so there's no way to do a white client there's no way to do simplified verification or anything so this is the first problem the second problem is that the activity inside of the master coin protocol cannot influence any state outside of the master grade meta protocol right so the master coin protocol can handle master points the masterpoint protocol cannot handle bitcoins so this basically really limits the functionality that it has so now we don't just have the bitcoin protocol we have the ethereum protocol and soon we'll have the ethereum 2.0 protocol so a question you might want to ask is can we try to use a similar idea so try to use any kind of second layer protocol that just uses the blockchain as a place to store data but does it differently in some way i mean in some way so that you do not have these issues right so um about four months ago i came up with this scheme that's now sometimes called ck roll up then um a team from the matter automated implementation and they called it ignis and then people from some other cryptocurrency projects called ignis got upset so then they call it adamus plasma and then plasma people got upset because it's not technically plasma if someone has a much better name for it i think we all um feel free to suggest it but there's this idea called zika roll-ups watching this watch whatever that basically increases scalability by a factor of 30 right now and possibly a factor of more than 30 in the future and it does this like that it does it by as follows right so first of all you have a contract so an ethereum contract and the contract um the contract storage only stores one value which is the numerical root of a market now inside of the merkle tree every single one of these values is just a pair of a public key and the balance now users sends transactions and the transactions that users send have a 13 bytes that basically say which account they're sending from which account they're sending to the value the fee and announce and a signature so users send these transactions and then there's a class of node called a relayer and what a relayer does is it gathers a set of transactions that users send and it creates a zika star and the ziki snark proves a few claims right so the first claim that it proves is that if you start if you start with a state that has some particular remarkable route so we'll call them or go greet r1 and then you apply all of the transactions from some set of transactions in order and these transactions then you get some other merkle root r2 and this r2 is the root of some other state which is the result of processing these transactions and all of these transactions are valid the elites about valid operations and they have valid signatures attached then the relayer publishes r1 r2 and the set of all the transactions to the chain and the contract in the chain verifies that the snark actually actually says that these transactions are correct so then once it does that it just inside of the contract replaces that state and and um takes out the sets the route from bmr1 to vmr2 so that's it that's what the contract does right now what does this give you now first of all this might seem like it's kind of similar to plasma right because in plasma you have a contract and the contract holds more coverage here you so you might ask well what is the difference right and the difference is that plasma needs to have a lot of complexity around things like exit games and the withdrawal periods because of this issue called the data availability problem right it needs to have a lot of complexity to deal with the possibility that a malicious plasma operator published a block with a merkle root but did not actually publish the data is if like if you publish incorrect data that's not a big problem because you can just prove that the data is incorrect with a broad proof to a smart contract but if you just don't publish the data then like no one can tell whether or not the data is valid is invalid what's in there and it's a kind of attack that's much harder to deal with now here we don't have a data on availability problem because all we're doing what we're doing is that we actually have to publish all of the transactions to chain now notice that here we're publishing the transactions without the signature right so what that means is that for every single operation you just have to publish 13 bytes now what's the gas cost of 13 bytes well does anyone know how much gas it costs in ethereum to include one byte in a transaction 68. does anyone know what 68 times 13 is 884. now does anyone know how much gas it takes to send the transaction down 21 000 right so we've gone from 21 000 to 884 and so how are we doing this right basically the reason why we can get these efficiencies i mean a lot is the largest part of it is because instead of verifying transaction signatures in by like instead of having the ethereum blockchain itself verify the signature of every transaction instead we use the zk star and the ziki snark basically proves that all of these these transactions actually are actually are valid and have valid signatures attached so we move the computation off chain the real layer does the computation we also save a lot of gas because that we all the storage gets moved off chain as well right so the storage gets moved off chain the only thing that stays on chain is the vertical route but because the data is published on chain we also kind of we also managed to avoid depending on a central real layer so we don't need to have a central operator the way plasma chains do and the reason basically is that because the data is published on chain everyone knows how to calculate how to compute the entire state tree and you can just process all of the transactions and if they have the state tree then like if the original operator disappears anyone else can just become a new operator in their place right so this is this is kind of kind of the basic pattern of at least one way to kind of use the blockchain mostly just as a place to store data now it turns out by the way that you can actually improve this even more and the way that you improve this is that it turns out that you do not need to include the non-sign chain right because the non-suggesting error for verification so if the nonce is there for verification but you don't need to know what the nonsense of the transactions are in order to calculate the changes to the statements so we can actually go down from 13 bytes to 11 bytes so 11 times 68 well 748 so yay even more efficiency so the cost of a roll of transaction way less than before now notice that unlike plasma this scheme can process instant deposits and instable straws now deposits and withdrawals are more expensive because they involve like actually taking moving um coins in and out of the system but they're very easy to do right basically the way that you do a withdrawal is if you have an account you provide a merkle branch and you the merkle branch proves that you have some state then you can extract those coins and the workload gets changed it was a numerical route where you don't have points anymore and the way that you would deposit is you provide a local branch that shows where the where the the highest index account is you would say how many coins you're adding and it also changes the work over it and it gives you a new account id and then you end up and it changes the route so depositing and withdrawing are both instant and you can do it without an operator and you don't need one central operator like the it's the concept of a relayer is just something that any like there could be many real layers floating around the network anyone can participate now um now this system could potentially increase scalability from of the ethereum blockchain from about for simple payments from about 15 transactions per second uh up to 500 but one of the takeaways that we had from the uh uh one east 1.

x workshop that we had in stanford a couple of months ago is that data in the ethereum blockchain is actually overpriced right so basically all that means is that the gas cost that we're currently charging 68 gas per uh per byte is actually kind of too expensive relative to the gas cost of the other operations right so like for example people are complaining about the state being and processing the blockchain taking a long time but actually like increase just adding um making blocks one kilobyte bigger but just by itself doesn't actually making any of those problems much worse right so even though the blockchain is in some ways kind of very close to the limits of its scalability in terms of data it looks like we can have a lot more data pretty safely and so it's possible that in like an upcoming hard fork the the gas cost would be reduced from 68 to something smaller and if that's the case and the scalability of this system could even go above a thousand transactions a second so taking roll up further right so what can we do with roll up well first of all we can support more complexity transition functions it doesn't just have to be sending money from a to b we could do a high performance exchange inside of this we could do human swap inside of it we could have multiple tokens we could try to do privacy preserving computations we could just do a whole we could do ens inside of it you can do a whole bunch of different things inside of this kind of setup and you can do it all using this kind of basic paradigm where you have you have an operator or relayers where relayers can update the merkle tree root and basically publish enough information that lets people compute compute the entire between themselves so huh so today i would like to introduce tada zk zk roloff um okay zk zk roll up um now if we have to name these things after seats of matter i'm going to call this bose einstein condensate but the easy get rollup sounds better so the idea here basically is that we're going to try to take the same kind of roll-up based approach but we're going to kind of make a mini version of z cash inside of this right so here's how you make a mini version of zcash so generally users publish transactions that contain snarks that say i have a valid spend certificate for some coin hash in the state and here's a new coin hash that i'm creating and here's a kind of unique value that i'm uh that i'm revealing and generally like one way to think about it is that a user secret which never gets revealed is some number s the coin hash is the hash of s plus one and the spend certificate is the hash of s plus two so what the snark does is it basically says when you publish a spend certificate it proves that the spend certificate is connected to the coin hash of one of or one of the coin hashes that already is in the merkle tree and that's it right so it proves that the span certificate is connected to one of the existing columns but it doesn't say which one the other important thing is that the verification function should also check that the spend certificate itself has not has not yet been revealed right so every coin has only one corresponding valence band certificate and so if you use a uh if you reveal a span certificate then like you should not be able to use that spent certificate again and this is kind of the basic way that it ensures this property of like one point goes in one point comes out without while at the same time giving you kind of total privacy within the set of users of the system so the transaction doesn't reveal which coin is spending each spend certificate can only be used once so this is like basically a simple version of zcash well how do we do it in inside of a roll-up so what we're going to do is we're going to say instead like a transaction here is just basically going to say here are some point here are the spend certificates i'm claiming here are some new coin hashes here's the values of these coin hashes here's a snark here's some other data but the real layer isn't going to be publishing the transactions the real layer is going to be publishing for every transaction a receipt and a receipt is basically just a minimal object that defines what is the change to the state that it's making because you don't actually need to publish the transactions all you need is to publish enough data to allow anyone who wants to to construct the tree up to that up to the current point and so the receipt would contain well first of all two spent certificates so assuming this is a utxo system so 32 bytes for one 32 bytes for one the values of the new points so you will make it be four bytes for efficiency and then we'll have a fee which might be one byte and if you want to create a bunch of new coins well it turns out you don't need 32 times n bytes you only need 32 bytes basically because instead of publishing all of the new coins you just publish the hash of the a root hash of your new coins and then the transaction that spends those points would have to provide a micro branch so all together we have basically 105 bytes multiplied by 68 and about 7 100 gas per transaction so still cheaper per transaction than simple dumb ethereum transactions but fully privacy preserving yes because you roll up so this these are intended as just kind of examples of the kinds of efficiencies that you can get and the reason why we get these efficiencies is because all of these systems involve some pretty heavy computation right like if you try to just do zcash on chain then one of these transactions would involve verifying a snark and verifying a snark involves like something like 500 000 gas now here what we're doing is we're not requiring the chain to verify a start for every transaction we're not even putting the stock on chain instead we're putting one single start where one single star can verifies that that for every transaction that gets included there is a start attached so it does require an of one level of recursion so it requires a snark of a set of snarks but what you get out of that is that the cost of verifying these things goes down from what it would be which is maybe 500 000 to what it what it could be here which is about 7 000. so now this all sounds good right this is like yay if we uh use things like snarks or potentially you can modify these systems to use kind of troublestyle interactive verification if you do these wonderful things then you can increase scalability by a factor of somewhere between 30 and 100 but okay well what if we want to do more so here's where ethereum 2.0 comes in right so the phase one of the ethereum 2.0 beacon chain um contain is basically is the phase that introduces a sharding of data right so phase one basically says we're going to turn on these 1024 shards each of these shards will have a block size it looks like the block stacks will be 16 kilobytes every six seconds and these shards would basically just contain data and the data doesn't necessarily necessarily mean anything so let's say you have this architecture well it looks like you all you do is all we've created is we've just created a chain that lets people throw 2.8 megabytes a second a second of jump onto it right well turns out we can do a lot of things with the junk so for example for example well how about we do zkzk roll up on top of it right every one of these every zika zika roll-up transaction is marginally 105 bytes 2.

8 megabytes a second of data availability 2.8 2.8 million divided by 105. that sounds like it's about 27 000 and yay we got 27 000 privacy preserving transactions a second so now and if we don't care about privacy well we can increase that by probably another factor of 10. yay wow i don't know i was i was going to make a snarky comment about how that's more than the scam coins have been pretending but i couldn't decide which campground to call out okay so this is what we could do right but there's a bit of a barrier and the barrier is that these systems that i talked about here right they don't like all of these systems rely on data but they do also rely on a computational layer they rely now their computational layer can be pretty tiny the computational layer basically just needs to verify a snark but it still requires computation and in phase one ethereum 2.

0 is not going to have computation now ethereum 1.0 has computation already right and so ethereum 1.0 has computation ethereum 2.0 has lots of lots of data well it sounds like we might need a bridge between the two and so this is what fortunately we can have if each two light clients inside of each one so we have uh spent uh quite a bit of time designing the ethereum 2.0 protocol to make it maximally like client friendly and the way that we do the do this is basically we have this architecture where if you've already authenticated some particular block then from that block you can often basically use merkle branches to authenticate a committee so you can use them to authenticate any random subset of validators and then you can use this committee to then verify signatures of blocks in the future right so basically this is the committee that will be used in the future to sign particularly to sign shard blocks and so you can then you see through these chart blocks you can authenticate future beacon chain blocks and so you can verify signatures and when you're verifying signatures you verify them against the validator set that you've authenticated against your existing block header and so you've now authenticated your way out to a new block header so in terms of the data complexity of all of this it's actually surprisingly same like basically about every nine days when the uh persistent committee switch you would need to authenticate a new validator set and that is about 80 kilobytes but you don't really even have to do the 80 kilograms all at once if you want you can kind of amortize it over the nine days and then if every time you want to authenticate a new header you would need about 500 bytes for the new header so you can almost do this in the ethereum 1.

0 chain as it is today the main challenge is that the ethereum 2.0 chain is using bls 12 381 and the um ethereum one chain does not have a good green compiler for bls123a1 and so if this gets added in the next fork then that problem gets solved so what this basically means is that you can have the ethereum one chain be the computational layer and then hook into the ethereum two chain and require the data for these uh roll up schemes we published on the ethereum 2 chain and then we can actually pretty quickly start to get these very large scalability gains so there's plenty of other things that you can do with the availability engines you don't just you it's not just about about doing roll-ups uh you can have plasma chains with much more frequent commitments so you can have plasma chains that make blocks every minute instead of instead of say like every day you can have dabs to store messages on chain you can have uh blockchain protocols that have their own kind of independence or sort of quote solver and speed transition functions so you can have kind of masterpoint style protocols but where they piggyback on the ethereum chain for data availability right so you can kind of do this uh mass a scalable version of this basic one protocol type thing where you you do just stick the data for your protocol on charts you use the ethereum chain for data availability but then everything else is up to you so that's one example of a kind of a layer to the for computation um i also wanted to bring up a different kind of example of a layer two for computation so speeding up crosstalk transactions right so one uh weakness of uh the current uh the current design for the ethereum 2.0 sharded chain is that communication between between different charts has a fairly a fairly long delay right so if you're doing things within one chart then you have a shard block that comes every six seconds and it's all nice and good if you want to do things between two between two shards then basically you have this approach where you do something on one chart then you have to wait until there's a cross link then the cross link makes it into the beacon chain and then you have a shard block that one that points to a block in the beacon chain that contains the cross link and then after one epoch your your receipt from the first shard makes it into the second chart so six minutes to move to move each ether to make operations between one chart and another at layer one that's a bit too long so can we make it faster and it turns out that there's a set of layer two techniques that we can use to make it faster pretty easily so here's how the layer two technique works right basically what we do is like we can the simplest way to explain this is that you can think of it as a think of like a token implementing this kind of scheme but you can generalize this to smart contracts you can generalize this to everything so here's how it works let's say at the top we have shard one and at the top alice has some number of coins and bob has some number of coins at the bottom we have a different chart and in a different chart we have alice bob and charlie and they have coins now at the beginning um alice has 10 points bob has 20 points charlie has 30 points and at this at that exact point in time on the other shard there is a transaction that sends five uh five more points to bob so what happens right so at the beginning alice has 10 bob has 20 charlie has 30 at the end alice has 10 bob has 25 charlie has 30 which is what should happen but can we give bob access to access to his coins faster so here's what we do let's suppose that we have some mechanism that allows one shard to see the roots of another shard that doesn't need to work all the time but that does work most of the time so one example would be that you can just require someone you can allow people to publish routes along with a security deposit right so they can publish a transaction into a smart contract that says i claim the vertical word on this chart is like it is 0x one two three four five and i agree to lose 100 ether if my claim is wrong then you publish this into a smart contract and now you have a unit of claim that says a merk of the merkle root on the other shard looks like it's probably this value now there's still some small chance that queen is wrong but if a guy's willing to put 100 ether behind it the claim is probably not wrong right so so what you do is basically you say in the token like inside of the the registry that stores the token balances you would define alice's balance of still being 10. cheryl would still be in 30. now for bob instead of his balance being a number is out his balance becomes this kind of conditional object that says i if our if the statement of the other shard is r i have 20 25 points if the state root of the other short is not r i have 20 points so it's kind of like representing a quantum superposition inside of a smart contract if that helps anyone at all um okay but basically like the contract itself kind of stores both states right it stores both possibilities and then only later when the contract figures out like what is the the actual uh root of the other chart then it knows like does bob actually have 25 points or does blob actually have 20 points so now here's the interesting thing about this let's say bob has 25 ifr else 20 points and let's say bob wants to send 22 points to charlie well bob can do that right so let's say bob wants to do that over here then bob's balance becomes three if r as 20 and charlie's balance becomes 52 if our else 30 right so you can just have these kind of superpositions propagate and that so if that happens then charlie's wallet can see oh look my balance is now 52 if or else 30.

well i'm going to decide for myself does it look like does from my outside point of view does it look like r is the root of this is the root hash of this chart if it is then my bound my wallet is going to show my balance as being 52 and if not my wallet is going to show my balance as being 30. so even though inside the state it's doing this funky stuff with weird superpositions from a user interface kind of high level abstracted point of view it just looks like bob is bob and charlie are getting their coins and have the ability to spend their points almost instantly so this is like one another example of the kind of thing leader twos can do a third interesting example is okay [Music] i just want to go one slide back up okay yeah this is the original shard so it was like so one forward and do you want four rings there we go so another thing that you can do with lawyer two is you can do end of general purpose privacy in different ways so there was this framework that was um introduced by alessandro ortiz and some other researchers a few months ago that'd be called zexia that basically creates a of utx does a utxo based a general purpose smart contract architecture that allows privacy preserving smart contracts and does this in a way that kind of actually looks and it looks and feels nice so you can do this and like basically this is like another example of what i would call a computational layer to right so the way that this would actually get implemented is that you would have these transactions go on chain and they would have snarks but like ultimately it is a kind of a different like people are programming in a totally different environment from the kind of basic environment that the ethereum 2.0 watching would provide so what are the so these are just different kinds of examples of things that i personally would call year two computation so what are the benefits of this paradigm right so philosophically here the idea basically is that layer one the ethereum blockchain's layer one does not need to be overly complex to optimize its properties it does not need to increase complexity to optimize block time to optimize cross-short communication time to optimize cross-sharp synchronous messaging support to optimize privacy basically layer one really does not need that much change and like theoretically i might even go so far as to claim that ethereum 2.0 phase 3 is like possibly just sufficient pretty much forever and with two exceptions one of them is that you would want to increase a sharp count eventually and the second is that eventually it wants to upgrade if the cryptography works but like aside from things like that it looks like you can do pretty much anything that you need online too right now there are obviously like other blockchains that have made this claim but like basically what i would argue is that once you have skilled like scalable data availability and enough explosivity at least to be able to verify things like zika snarks and vr5 basic state transitions then as long as you like past some minimal threshold of kind of power and some minimal threshold of complexity then you actually can kind of build these layers on top and do all of the upgrades that you need to do from there right so we don't even need to do a kind of ethereum 3.0 super quadratic sharding there's a lot of things that we kind of don't need to do if we did just we decided to do but we managed to do this kind of way that's a way layer 2 approach for scalability and privacy and then usability innovation instead and [Music] so that's so this is kind of a possible long-term roadmap for the ethereum ecosystem right so basically like over time it's possible that layer one is just going to be harder and harder to change and but if that happens then that's all fine because well we can do so many cool things with these computational layer 2s and computational layer 2 is actually become really friendly and really easy to make and use if you're basically you're building them on top of scalable base layer data availability so if you have data availability of in this case we'll start off with 2.

8 megabytes a second and potentially like you might have plug forks to increase it over time but like if you have even that much then there's just a huge number of cool things that you can build on top in different ways thank you [Applause] uh yay questions yes yeah just uh the layer two computation to scale that doesn't that preclude like two ring complete languages i thought that doesn't work with the zk starts um so there's a difference between between like basically when mathematics when mathematicians talk about certain completeness they actually mean a different thing than what the crypto community means when they talk about during completeness and like mathematics like we should all really use like use language late now the way the mathematicians do like basically touring completeness as mathematicians use that basically means that you keep like you computational languages that are so general that you can't tell when the computation is going to halt and that's something that you can't see with a start because with us north you have to know ahead of time how many steps it's going to take the thing that kind of crypto people sometimes accidentally like use the word touring complete to mean is basically kind of being expressive enough to have to be able to express applications that have complex internal state so to be able to express things like plasma things like uh you know think meeker dao things like units block you know whatever the verification engines for these layer twos and things like that and like bitcoin for example is definitely not powerful to do that if you're in for example he is powerful enough to do that and sexy is a utxo based model but it also is powerful enough to do that so now touring complete is really the wrong word to use for this stuff but it's that but like it is the case that you can do things that are expressive enough for the applications he wants to build and inside of keeping there yes can i ask something before this before serenity i mean uh in the fair market we have lower we are reducing uh the the hash power maybe we lost maybe 30 percent hash power and what do you think about because we are going to we are going to uh first starting and the less harsh power is less security what do you think about this and how can our community to solve this problem because lower hash power and lower security something um i mean it's definitely a challenge of an issue though i would say that the ethereum's current level of hash power is not close to being low enough that we need to worry about it so like for example the ethereum classic chain has been attacked and you know that's one of the most powerful chains that has been attacked but the ethereum classic chain only has like something like three percent of the hash power that the ethereum has so like there is still a pretty wide margin between the two i mean if it turns out that like that the um ethereum chain you know becomes attackable and say like in say more than six months from now then another thing that we can do is once phase zero is launched we can actually modify the proof of proof-of-work clients to basically treat the phase zero proof of stake as being a finality mechanism and if you do that then 51 attack self-improvement work chain can't revert finalized blocks anymore the only thing they can do with sensor blocks so that would also reduce the reduce the risk in the system by making 51 attacks less dangerous if they do happen yes sounds like that there's always of the degree of decentralization between production layer and application i mean when we want to make the blockchain more language then we need uh data providers and somehow make that is true um one of the reasons why i think this class of literature that i talk about today is interesting is that because it doesn't need to solve data availability problems the level of application layer centralization is actually reduced by a lot so for example like if you compare plasma versus rollout right in plasma because you have like you you have to see the availability problem you need to have an operator and then if the operator is malicious the operator can't steal your coins but the operator can't make everyone waste their time getting their points back for two weeks whereas with roll up like because there isn't a data availability issue if one uh real ear disappears another real layer can just immediately pop in and take their place so the amount of harm that a malicious relayer can do is like much lower in roll-up versus in uh something like plasma so now i mean i do agree that kind of being like too open to send a centralization out later too is it is risky but i would argue that like it's the earlier tears of of this kind in particular are more a part of the solution than a problem yes uh principle thanks for a great talk and i think the idea of having conditional states and i was wondering are you guys considering around like something like too faced permit vertical when doing cross shot transactions um so we have uh something that uh something called contract yanking which is one way of like solving what we call a training what we call trade in hotel problems like basically the idea is that if he wants to interact with two objects that are on two different charts then you first take one off like send a transaction to take one object and move it from one chair to another and then that might fail it might succeed only if it succeeds you do it then you have two objects on the same chart you can do one thing i say one thing synchronously with them now people have talked about the idea of like should the ethereum blockchain support kind of like actually asynchronous crosshard um activity and at layer one and so far i think our answer has been like we thought about it and the answer has been no so far basically because it would introduce too much complexity like the idea is that right now like in between across in between two crosslinks you can basically define like calculate the state the state transitions of a shard as just being a function of the data in that chart and the beacon chain and it doesn't depend on anything that happens in other shards and so if we were to have a base layer from synchronous short calls then it would break that invariant and it would make the state calculation game much more complicated but the good news is that you can i'm quite sure that you can make a layer two from florida but you can basically use the same kinds of techniques that i talk about here and just make a layer two that supports uh synchronous crop short calls synthetic solution for these theorems and for example the center is technology the large part of balance and what is the relationship between those synthetic solutions um so silver is a state channel system so it basically is um and it is one of these kind of or like it is part of the kind of lawyer too that provides itself its own data availability solution so it is like it does involve data being off chain and state channels like have their own benefits so probably the biggest one is that they support instant transactions and that's like like state channels are one kind of layer two plasma is another kind of layer two and they're both part of this larger kind of group of layered two is that that that try to handle data availability issues themselves with a data arcade what i talked about here are the layered tools that do computation off-chain that have data available availability all be handled by the chain because all the data is on chain so it's a different kind of thing with different trade ups alright so thank you