The Data Availability Problem - Vitalik Buterin | Silicon Valley Ethereum Meetup

Transcript

all right our last talk before we get to the panel is by a vitalik who's gonna tell us about the future with your him great ok so um today yeah I'm going to and I'll also try my best to make the sub shorter than what I did what I did yesterday yeah in San Francisco but I'm going to talk about basely or blockchain scaling and try to give a kind of more precise understanding of you know basically what is it that makes scaling blockchain a scaling block chains and specifically scaling block chains to the points where they process more transactions than what in one single computer can process a very difficult problem and particularly later on I'm

going to talk about something called the data availability problem which turns out to be one of the main challenges in doing this sort of thing so it's a start off just to introduce a bit of notation this is called a watch in it contains blocks every block contains transactions those arrows represent every block containing the hash of the previous block everyone still following now I'm good at represents their computational capacity of a node so C is basically the quantity of the number of transactions that a node can process we will say per second we can say per block interval

either in terms of computation or in terms of storage requirements or in terms of bandwidth we just assumed that all of these are proportional and roughly equivalent to each other and in a simple chain and we'll also say that the transaction capacity of the network is also going to have to be ofc and the reason for this is simple because if the transaction capacity of a network is greater then see our antenna of C then that means that nodes can't process all the transactions nobody can run a full node and so the watching doesn't work anymore right so there's a few incomplete so a ways to scale of watchin so all of these are technically scaling

solutions but they come with serious drawbacks so here's the first one super big blocks right so increasing block sizes definitely does have its place and you know there are I think there's definitely a lot of cases where you can get it quite a lot just by increasing a few constants up but if this is your only scaling strategy and you try to push it to the limit then you have a problem so a problem basically is that if we increase this from C to a thousand times C then okay the network capacity goes up from C to a thousand times C you've increased your transactions per second by a factor of a thousand but the load on each validator also goes up by a factor of a thousand

so the amount of transactions that each node has to process only goes up by a factor of a thousand but you know we've made an assumption already that this is larger than the amount of transactions that are known that a regular computer can process and so your only notes are going to be inside of data centers so this is strategy number one this is strategy number two and this is kind of the strategy that the crypto space has already been implicitly going towards whether intentionally or not right so big one transaction fees in many cases over a dollar and some sometimes over five dollars well okay fine use Bitcoin cash well Bitcoin cash transaction fees go

higher well use aetherium well by theorem transaction fees go higher use of theorem classic if you're a classic transaction fees go higher we'll use those those transactions are still cheap right so basically just like capable hands you know if we gets to a quote mainstream adoption you know we'll be going all the way down the list until we gets to you know be making transactions and coins with names like Trump Coit and projects a quorum so this is technically a scale a solution right and this gives you a network capacity of a thousand times see the validator load is only seen because you know it's every every user only really needs to be a node on

one blockchain and you know that each individual blockchain is still only going to have or see capacity the problem is each and every one of these chains is going to have 1000 times the lower security so you know if you look at Trump coin while the market cap is something like $600,000 well probably any single one of you could basically if you really wanted to afford the money to personally run a 51% attack on their blockchain so you know this is like look so this is a second approach now merge mining is another approach and this basically says we have a thousand old coins but we let people mind many old coins at the same time the problem is this also doesn't solve the problem and

the reason is that you know you have the main parameter that you can adjust here is the like on average how many old coins does each miner end up mining if the number is close to one then you're not actually gaining much security each individual or coin is still you know a thousand times I'm easier to attack than it was before but if you're going if the number is very high so if the number is close to all of them then basically miners still have to process every transaction and so you've actually done basically the exact same thing is this except technically it's split up into a thousand bug the the data structure is slightly different but the effect is basically the same so it looks like we have a scalability trilemma here right

so the trilemma claims that I mean look now this is not enough so we're in absolute facts right and as I'm going to clean a later claim there are ways to get around this but it's very hard to get around this in the trail of a claims that blockchain systems can only have at most to over the following three properties so the first property is decentralization and intuitively it basically means the network can run as Wanya and entirely on the basis of random ordinary guys with laptops this is the definition of decentralization the next so basically do not require data centers you do not require like super nodes you know you do not require

any you know basically any particular kind of you know cluster of that or any one category of user to have you know a more special special status that other users do not i'm scalability diff Linda's being able to process more transactions than a laptop can process so in this case you know in computer science notation Oh have an extra greater than ofc in security being secured against attackers with up to O of n resources and the best way to interpret this is basically being secure against attackers that have up to some up to some fixed percentage of the network so you have 51% attack for a naive proof-of-work attack

all right you have 51% you have 34% of percents to break the asynchronous visiting fault tolerant consensus you have a zero to thirty four percent or 25 percent with the fixed and you selfish mining attacks and so on and so forth so um what you do what you're not allowed to have is a security balance are that goes down and or in an attack with threshold that goes down and down the higher the scalability goes right so it's actually fairly easy to get two out of these three so we can have decentralization and security with our a simple blockchain you know like pick one

and aetherium as they exist today we can have scalability and security with super big blocks and we can have decentralization and scalability with the thousand all coins can we have all three well this gets very tricky so we're going to take a bit of a detour into something called interactive computation or sometimes interactive verification so the set up for the interactive verification game is like this let's suppose that you have some function that you're so some long computation that you're trying to make and this computation is you know something that just takes an extremely long amount of time so but it has the property that it's a function that can

be decomposed into a large number of different functions where if you take if you start off with some input X and you know your the function itself becomes a composition so F is a composition of F FN FN minus 1 all the way down to F 1 so if you would take a look at all the intermediate values F 1 of X then than the value after of to the value F 2 F 3 every single intermediate value is also your basically are very small in size so specifically at most o FC in size so if you have a proper this computation that has this property that it is is just a long string of opera a list of value being strung through a chain of functions we are at every step along the way the value remains small then we can play this this simple kind

of game and basically we can give we can kind of trustfully compute the value of F using a block chain as a verification aid but without doing everything on the watch in so here is the first step the submitter is gonna send it is gonna process you know take X and run through F 1 F 2 F 3 yet all the way down to F n and the submitter is gonna send each transaction which is like a solution candidate right and the solution candidate is going is gonna contain it's obviously gonna guess obvious we're gonna get to in why the answer but it's also going to contain s 1 which is we're in the value that you get after you take

X and you apply F 1 to it s 2 so s 1 butterflying applying F 2 to what s 3 so a s 2 but applying F 3 to it and so on and so forth all the way down to a n which is basically the same thing as Y now the submitter also saw a sense a transaction the transaction contains all these intermediate values and the submitter submits this along with the deposit so first of all we can immediately tell right now if this scheme works what is the maximum computational complexity of F that can be processed so if this is done inside of a simple block chain then the block chain has ofc capacity so you know the gas limit is ofc and first of all what

we're going later on we are going to depend on the ability to compute any fi inside the blockchain so the computational complexity of each individual fi can only be ofc and because we have to submit all of these in one transaction the number of these s values and so the number of F values is also going to have to be at most ofc ofc x ofc means that f can have a complexity of at most ofc squared so what's the next step here once the submitter submits the solution candidate there is some challenge period this could be an hour could be a day could be a week could be five minutes if you're feeling really daring within this

challenge period anyone can submit a challenge index and a challenge index is basically saying hey look this particular solution is wrong and it's wrong right over here so if for example you see you know there's some some computation and you just decide to randomly audit it and let's say you randomly odd you know you go and you take the value s 42 that got submitted and you just personally try to apply F 43 I'm f 43 and you notice that the s 43 value that you compute is not the same as the s 43 value that the guy submitted so you notice that there was an error in the submission you can send a challenge transaction and as one of the arguments

to the challenge transaction so this is going to be calling a function and that's the argument and the argument is going to be this index 43 now what happens then is that the contract actually is going and executes F 4 in this case F 43 inside the EVM inside consensus and it's going to execute it on s 4 s 42 and it's gonna see AF it actually gets the same s 43 that was supplied in the transaction if it was then you're just raising a false alarm and you get nothing and you just wasted a huge pile of gas but if the yeah you know it turns out the contract notices that this particular answer that was submitted actually is wrong then the Challenger gets some portion of this of

the submitters deposit and so this is the incentive for people to do this kind of audit in if no challenges or challenges are made within some challenge period then the submitter gets the deposit back the submitter gets the reward and the system kind of assumes that the submission is correct so this is kind of the basic idea behind interactive computation now you can actually extend this and there's two ways to extend it so the first way else that if you wants to turn this in if he wants to increase the capacity down with capacity from ofc squared - Oh F - to the 2 ^ C so make it exponential then you can play this multi-step game or basically this emitter submits three

values of M a challenge you're asked to say either you're wrong on the lobster you're wrong on the right and then the Challenger has to provide the value in the middle then the submitter can kind of contest the challenge and say either you're wrong on the lottery you're wrong on the right and so you do this sort of interactive binary search until eventually you get down to the bottom and on the bottom you do it on chain so you can do this sort of thing and another thing that you can do is you can also actually extend interactive computation so that it works with computations where the values in the middle are too big - into basically bigger than ofc so you can't what put me in an entire intermediate result on onto the blockchain all at once and the way

you do this is with Merkle trees so in when I present to this in San Francisco it required everyone to battle to Ralph Merkle so require everyone here to do the same so everyone should be really thankful for this guy because you know it really is me you know who here has some synced in aetherium white client who here has synced a GAF full node at any time in the last year parody node in all of you have saved hundreds of gigabytes of bandwidth because of Tekken all the sky okay so for those who don't know what Merkle trees are basically

they are they allow for efficiently verifiable proofs that basically if some piece of data is a member of some much bigger piece of data so if you want to make this much more abstract you can assume that let's say you're having one megabyte file you're going to make in this kind of complicated hash construction out of the one megabyte file and eventually you're gonna create a it's gonna have a 32 byte root hash at the top and so you might want what you might want to do later is you might want to prove that some particular value is in some particular position in the original data when the original data is kind of publicly represented by the route hash so what you do is you basically have all of these all of these hashes and

basically you provide in the merkel the moral proof or sometimes called the Merkel branch is just a set of hashes that goes from the root specifically down the chain going all that we're going along the this kind of path to the specific value that you're trying to give a proof of and so someone can check the proof basically by checking that the hashes match up at every step along the way and if they match up then the proof is correct now if someone tries to create a false value and tamika Merkel a false value then at some point the hashes are not going to match up so this is what Merkel proofs do now the idea basically is that and you know Merkel trees actually get used

a lot in aetherium and the other major use case in ethereum is that they use them for the state tree right so the state in aetherium is basically the set of all accounts and the set of all contract storage for all contracts so basically all of the kind of information that you would needs to have in order to process and verify transactions and just know what the state of things is right now now this is stored in this in this kind of special hash tree and any particular state it can be represented by this 32 byte root hash that we call the state root and so state roots are you know you need basically uniquely maps to the state and so if I have the state root then theoretically I can use

that to authenticate the entire state so all of the accounts all the every single piece of storage and every single contract all of the balances but in order to authenticate any individual piece of the state I would need a miracle branch and the Merkel branch basically just needs the hashes going down from the root all the way down down along some particular path in the tree so the way that we can think about fraud proofs yes that fraud proofs kind of are an application of interactive computation to verifying the watching so but here is kind of what I what I mean by this so you can think of verifying the an entire

blockchain so verifying a blockchain you know from Genesis to a 4.3 3 9 million where it is right now as kind of like being an F at this F function right so it spits in it's an F that decomposes into F 1 by F n very naturally X is the genisis state and we can think about that you can think about the state as being the state route right so you can kind of I think about the state the state here is just being the root hash F 1 is apply for the first block to the genesis state what is the state after that F 2 is take the state after block 1 and apply block 2 F 3 is supply block 3 and so on and so forth until FN is apply

like the last block in the chain so right now block goes to four point two nine million now there is one important one important difference here though bits between verifying a blockchain and this simple case that we talked about earlier so as we are flying a blockchain right so first of all what do we know that you know what can we kind of allow users to have right so you can require like clients to download every single block header right so every block has this like piece of data at the top called the block header and the block headers purpose is basically to contain the a reference to the previous block and to contain a whole bunch of data that are

and contain root hashes so a hash of the transaction tree a hash of the and a hash of the estate of this of the state the so the the root hash of the state after processing all those transactions so we can assume that every year you know let's say we have a type of user a light client that can download all of these all of these block headers but they do not have enough capacity to download and process all of the blocks and so what we do is we're gonna basically do a kind of a very similar thing what we're going to say is that a light client is just going to actively listen on the network for challenges and what is a challenge well a challenge

basically says walking you know in this predict in this chain that you got block number three million eight hundred forty nine thousand two hundred twenty three is wrong now the main difference here though is that you because you're operating over trends a large sets of transactions and because you're operating over large states and the white clients by itself is not going to store the state and it's also not going to download all of the transactions basically a challenge has to also provide witness data so what do we mean by witness data basically the blood the the light client already has all the block headers and so the white client has the Morgul tree root over the transactions in the blocks and of the

state after processing each block so you can think of that as being like these si values but what they do not have is a delight client does not have the actual transactions and the white boy does not have any portions of the state they're in any block these are values that the light client can authenticate if you provide them well with Merkel branches but these aren't values that the light client has yet and so a challenge has to be not just to challenge index but also witness data right also the Merkel branches that allow that basically tell you you know this is the the actual set of transactions in this particular block and this and this is the portion of the state that was modified by this

particular block so that the white coins can actually run through all the computations and check whether the state root after processing the block is correct or incorrect so because you're operating on these large sets of data and because so because it's not like a from the kind of white clients point of view it's not a pure computation it's this kind of computation that keeps on constantly accessing this extra data from the outside you have two challenges also have to provide this witness data as well now so what is a fraud proof basically a fraud proof is a challenge index plus all of the witness data so the transactions and they're kind of branches in the state that you need to

execute a particular block and so like clients can execute if it receives a challenge it can actually verify only that particular block and you can check for itself whether the block is actually valid or not now this is so far theoretically doable but there is a problem and the problem is data unavailability attacks [Music] so did unavailability attacks are basically attacks where a malicious miner creates or publishes a block that the block header is present but some or all of the block data is missing right so you can think of this as being a

block that has a transactions well the first transaction here it could be a valid transaction it could be an invalid transaction but whoever published the block is not publishing it I mean so now first of all what can data unavailability attacks do you know what is the worst that can happen because of a data unavailability attack the first thing that the attack can do is it can convince the network to accept invalid blocks and particularly there's no way to prove invalidity right so this transaction over here could be a valid transaction or it could be an invalid transaction that gives me 50 million ether out of nowhere if you do not have the data you have no way of verifying

which is which and technically in an information theoretic sense there's a node there is basically an infinite number of valid transactions that have the same hash so it really could be any of them and there's also an infinite number of invalid transactions that have the same hash so it could be any of those so that's the first thing that you can do but now yes there you might think oh well we have you may have heard of weird spooky fancy math called ZJ snarks your knowledge proofs or ZK Starks and these basically let you prove the block is valid and so what you prove that your or more specifically let you prove that my block header is valid without reveal actually revealing any of the data right so you might think oh well we have this kind of fancy

cryptographic magic well we just let the cryptographic fancy magic proof for us that all these blocks are valid and that we don't need to we don't need to care about the data well it turns out that even in that case there are other very nasty things that data unavailability attacks can do so particularly if you prevent someone from learning about a transaction then even if they have this the new state route and even if they have this magic cryptographic proof that the new state route is correct what they do not have is the entire new state they have no idea what the balance of certain accounts is you know they might be able to download some of the branches but they're not gonna be able to download all of them and so what you need data unavailability attack could do is

basically you know if it could just prevent people from knowing what the current state of certain accounts is and what the even nastier thing that happens after that is that if you do not know what the state of some account is then you cannot create your own transactions that interact with it right so the network how if an attacker makes this one invalid block or a sir this one I'm partially unavailable block publishes it and if this gets accepted then this attacker disappears every all the other participants in the system are not going to be able to agree on blocks that contain transactions that touch these affected accounts because nobody has the

information that they need to make a cryptographic proof so the cryptographic proof could be a miracle branch it could be some kind of fancy witness scheme it could be you know it could be whatever and this applies to aetherium like account systems that applies to Bitcoin like UT EXO systems it applies to you know what basically any kind of design so does everyone agree that data unavailability attacks are bad who here thinks the data unavailability attacks are good okay so the data unavailability problem right so in correctness can be proven even to a light point and this is basically done with fraud purse right

even if you cannot verify directly you can always verify indirectly but data unavailability is not like fraud or is not like fraud in the sense of creating invalid blocks and the main difference is the data unavailability is not a uniquely attributable fault so what do we mean by unique we generated well fault basically it's a false where if it happens you know who did it now well with such an invalid block there it's totally attributable because if someone creates an invalid block while there's you know in proof of stake you have a signature attached or improvement work you have kind of this one-time identity in term with no was a proof-of-work solution and you know that

no it was this minor that caused the problem or then it was it was this validator that caused the problem and so he can deny them a reward or he can penalize them and you know this gives you all the right economic incentives to disincentivize them from doing any sort of nasty stuff now we'll see an honor the unavailability the problem is basically this so let's go through two possible cases and these are just two possible sequences of events that could happen at some point so here's case one at time T one validator V one who is evil because he has horns anyone here have horns on and are not evil oh okay I can be racist against horn people so a validator V one

publishes a block was missing data right so valid everyone publishes a block and this one tiny piece of the block is just not there it's missing it has not been published against the network or a published to the network time t2 validator v2 raises an alarm ray basically says hey this piece of data is missing log log Wow I'm afraid at time t3 value review one goes ahead and just now publishes the remaining data right so basically a validator just says okay fine you raise the alarm on publishing the rest of the thing now here is case to a validator v1 who in this case no longer has doradora has horns publishes

a block and the block actually does contain all of the data at time t2 evaluator v2 so the Challenger who is now evil raises a false alarm so basically says look lug the state is missing when it's actually there at time t3 in this case valid review one just does nothing now here's the interesting thing about this story from the point of view of any client that log that logs on or that appears or that starts paying attention to this piece of data after time t3 case one in case two are completely indistinguishable from each other so after time t3 all that you see is there is a full fully published block

and there's an alarm but you have no idea whether it was case one or case two that gave rise to the situation so this leads to something that I call the fisherman's dilemma and it's called the fisherman's dilemma basically because fisherman is a technical term for P of Alex specialized nodes in the network that do this right so the fisherman's the llama basically says in let's suppose that we are living in case one what is the expected return of validator v2 and there is water only three cases right there's three kinds of real numbers so there's some real numbers corresponding to people who can count in

real numbers corresponding to people who can't that was a joke no so there is real numbers greater than zero gril real numbers equal to zero and the real numbers less than zero so first of all real numbers greater than zero right so what if the expected return of v2 is positive in this case what this actually means is that there is a money pump vulnerability right so what the money pop vulnerability means is that in case two basically validator v2 also makes a profit and so what this means is that there's profit to be made by just going around and raising false alarms all over the place this is bad now let's say it equals zero well if it equals zero then there's no

money pump vulnerability but what there is is it's an isle of service vulnerability because validator v2 can just raise alarms for every single chunk of every single block of data until everyone is forced to download everything and if everyone is forced to download everything then that contradicts our goal of scalability because you know we're assuming that in each individual client has OFC resources and they're being forced to down download more than or C data if the block chains capacity is more than ofc keester in the other cases the expected return is less than zero so v2 loses now that's good in case two because you know it means that that it's cost way to do this kind of attack but in case one what this means is that there's no incentive

first of all there's no incentive to raise the alarm and second of all there's a disincentive against raising the alarm and so what an attacker can do is basically they can just keep on publishing blocks with missing data they can wait for they can let the altruistic a challenge a challenge or such keep challenging then they can just outlast the altruistic challengers thank you just wait until the altruistic challengers run out of money and when they run out of money they can keep publishing blocks for missing data and these blocks could be valid or invalid and the clients will just give up and accept them so this is kind of well this is kind of why a fraud proof like approach to data availability is just

not going to work so there's two main categories of solutions to this the first category is you rely on an honest measure of on an oralist majority assumption and you use random sampling so basically the idea is that for like you can imagine a blockchain that's kind of you know a short in walk chain so you would have like a hundred different kind of universes and these would be a hundred separate sets of accounts and within each university would also have a hundred separate groups of transactions and you would just randomly assign some group of validators so I'm too you know a verify of a liqu validity or even just verify availability of let's say everything on

shard 1 or everything on chart 2 everything or you know you might create a committee for shard 43 basically create a separate committee for each individual shard right or for each individual kind of universe of accounts and transactions then then basically everyone would just trust the committee right so each committee would be responsible for downloading all of the data and if if the committee says that the data is available then we basically just trust that the data actually is available so this is one solution but this crucially relies on an honest majority assumption the other kind of solution basically has to do with the

client-side random sampling so a client-side random sampling the idea basically is you know select you have this big hunk of data and you only have that you only have the while each individual client only has like the root hashes of the data and so the client basically tries to determine if the days of data is available by doing random sampling right so you just randomly select a bunch of indices try downloading some transactions that have those indices you know just random will you pick index number 623 each try to download transaction number 623 pick index 285 try to download transaction 285 do this 100 times if this passes then it looks like all the data is

available so this works well against attackers that try to withhold all of the data or against attackers I tried even attackers they try to withhold half of the data but it does not work well against is attackers I try to withhold a tiny piece of data right so if an attacker withholds only one single transaction then Rin this kind of random sampling is not gonna work and so you're basically going to have to a client is gonna have to download everything in order to verify that there isn't a single missing transaction and as we all know a single missing transaction is basically enough to completely wreck the system right because able to single missing transaction you know I could that

transaction could be an invalid transaction and I could give myself 50 million ether fortunately you know we have erasure codes you know error correcting codes basically a bunch of fancy math that specializes in turning 100% availability problems into 50 percent availability problems so the usual mathematical explanation I give for this is if you have a piece of data then you can encode the data as two as two points so you can encode the data as two points though you would put on a plane you draw a line going between those two points then take a bunch of other points on that line so any two points on that line are enough to reconstruct the original line and

therefore any tuple any of those two points are enough to reconstruct your original data so this is how you solve a kind of two of two problem or you turn it to of two problem into a to a four problem now if you go from lines to high degree polynomials then instead of it being two event you can make it be a thousand of two thousand or you know ten thousand of twenty thousand or be like whatever exponents you want right so what this basically the idea here then instead you know basically you if you have a block we have some transactions and the transactions are for Merkle tree then you would just make another Merkle tree out of this extra data that gets added so you can think of this as being like these extra points on a polynomial

and any at any 50% of all these values together or enough to recover the original data and so clients can just like sample for this to determine sample through this in order to kind of probabilistically get an idea of availability now in order for this to work you also need and not to add another kind of fraud proof so the other kind of fraud Bruford basically say this all look for this particular block this one the erasure code is actually malformed and it's malformed because you know look if you actually try to reconstruct the whole thing then you get an inconsistency but if you have that then you can kind of use this mechanism to verify that data actually is available this is kind of similar to

proofs of retrieve ability and like a lot of similar math is used but the main difference key basically that Anna proof of retrieve ability its Alice sends Bob a file and then Bob that that's means we assume that Alice is trusted so we assumed that Grover creates the file was trusted and B severe the ones that send the challenge or possibly a third party that sends a challenge and bob has to reply back with a valid response here the main difference basically is that the person who is creating and uploading the file is also untrusted so but you know or alternatively in this case Alice is Bob but you have third parties and arbitrary third parties that once guarantees about the availability of the file and about

the the the wall for bonus of the erasure code and also about you know the is the file actually correct according to the rules of the protocol so they are I mean there are are actually some in the it is kind of computationally viable a lot of this still can be improved much more but you know it's another important kind of path forward is trying to combine a lot like a lot of this stuff with zero knowledge proof because of your knowledge proof so you can remove the need for fraud proofs so this is a kind of more high-tech direction for the verifying data data availability that key and it doesn't rely on trust

assumptions as much now my opinion is that if you want a maximum security solution then you can basically layer these two schemes on top of each other and so you can say you know a regular node should accept the block is finalized if number one the Committee says it's okay and number two its valid and number or sorry and number two of the sampling says the data is available and number three it hasn't seen a frog proof yet so if all three of those checks pass then you know and that gives you a quite a strong guarantee that the data actually is available and valid so this is probably the chlorine the closest that it's seen that it seems

like you could get to kind of verifying availability and correctness of data much larger than o of C with only ofc resources I mean in but so basically with this kind of technique you can view you know you could imagine a blockchain where the total capacity of this you know you also have a shortage system so the kind of transactions are split into these different universes so it can be executed in parallel on different nodes and the total capacity of the chain might be something like ofc squared because you know you have ofc different shards and they each card has ofc capacity and then you have like a top level mechanism that keeps track of all the shards so yeah so you have ofc of those in soil and then but we are each individual node does not need to

have more than RC processing power and where individual clients also do not need to have more than ofc processing power in order to stave or verify any one particular shard yeah so this yeah if you wants to increase the kind of base layer capacity of a chain from ofc two ofc squared and do so while preserving all these like these kind of decentralization and security properties this seems like this sort of direct in this sort of direction that it makes sense to go and at least if he wants to guarantee you know availability and correctness so thank you [Applause]