Ethereum 2.0-custody game

Transcript

so last but not least in our trifecta of Awesome aetherium 2.0 researchers I'd like to welcome to the stage to talk about the east to custody game Justin Drake okay thank you okay so I'm going to talk about phase one of a film 2.0 which is the the data layer and specifically I'm going to talk about the data availability problem which comes

with having lots of data and even more specifically I'm going to talk about the custody game which is one of the solutions to data availability so three parts in the talk what is the data availability problem what are some of the solutions that we intend to deploy in in phase one and in the future and then a deep dive into the custody but game which was recently simplified okay so what is the data availability availability problem so basically you have data and you can reference that data where some sort of identifier which is six things like a 32-bit byte hash

and the question is if you only given the hash and not and you don't have the data is is the data available to you can you actually go ahead and download it and one very like a simple approach which is kind of the naive brute-force approach is that you just go ahead and try to download the data and then you will know whether or not you can download the data and that's perfectly fine for from 1.0 and for the beacon chain because these are you know very small chains and every valid data which we assume to be you know a laptop on the on the home connection can can download without any problems but this is

unscalable this kind of naive approach especially in the context of so even though one single shard has totally reasonable bandwidth you know let's say on the order of 1 megabyte per minute once you have a thousand shards then it becomes a lot more data on the order of 1 gigabyte per minute and so you know how do we deal with all this data and like the scalability solution of a firm 2.0 is that everyone doesn't download all the data and it's just there's just too much data for the validates it's download so what we do is that we take the shots and we kind of segment them into into a box and then for each epoch we have so called cross link data which is going to be the data

in the shards plus the data in the headers and this cross link data that is 16 megabits which is 2 megabytes and the reason I'm talking in bits will be will be relevant later and what we have is that we have these references from the beacon chain to to the shard data so we have these so-called cross links which are the yellow stars and the hashes which are the the purple rectangles and they're pointing to data and so as a validate of the beacon chain you only see these very 16 cross links and you want to have high guarantees that the data that these cross links are pointing

to are indeed available ok so let's not look you know too much as to what's in the data we can forget it's you know blocks and headers let's just assume it's a blob of data and what are the steps to kind of creating a cross link in 2.0 so the first step is to mark relize so we have this hash tree root so instead of taking a simple hash we we merkel I so that just did that a detail we have this identifier which is a data root and then the DIA testa's which are basically validators in a committee assigned to this very specific

cross link data are meant to download the data and and sign it if they are able to sign it so they kind of vouching that is available it's downloadable and then the various at the stations are aggregated from across the committee using BLS aggregation and then once you reach a certain threshold which is enshrined in the protocol then you get the the yellow star and you are a cross link and these cross-links go in the beacon chain and so you know to rephrase it data availability problem how do we know that you know from the cross link you can recover the data if you're not a validator that you know was assigned to this specific cross link and the reason

that you really want to know that the date of it is available is that if for some reason or another this data is not available then that means that you can't download it the in general can download it then you have a so-called unavailable cross link and this is like super toxic waste that will pollute the beacon chain extremely fast and so if if this happens then you know emergency mechanisms needs to come in place we need to do manual roll back all the way back to when when there wasn't this unavailable across Mac so this is one of the the main problems of phase one and we're going to see how

how we can solve this program so in phase one we're gonna have three solutions to to the data validity program so one is going to involve cross linking which is a process it just walks through but I will give more details as to why it works and then we're going to go through custody proofs which is like the the main content of this talk and then there's also a mechanism which is the chunk challenges and you can kind of think of them as kind of on a time axis where the custody proofs are proofs that you have the data and you can only build them when you have the data so they're

kind of before even committing to having the data so that kind of in the past relative to cross link cross link is a real-time thing you know you're committing to having seen the having seen the data in real time and then the chunk challenges is basically a thing that happens post factor which is oh you know use you committed to this data please give me this this random chunk in of the data that happens post facto so and then in phase 3 a plus or maybe in the film 3.0 I don't really know or maybe even in phase 2 if if if we're very aggressive we have something more

fancy which we call availability proofs and these use kind of fancy math and tricks like razor code and Starks and I won't go into details that's I guess for never talk ok so let's see why cross links work so the reason cross links works under a certain secure security model that we have any theorem 2.0 namely that you know an honest majority assumption is because we have this this pool a very large pool let's say a million validators and we're assuming that two-thirds are honest so they will follow the protocol rules which includes

downloading the data so 2/3 are honest to further Angels & Demons and when you have a pretty good random number generator such as R and L then and you have a a cross link Committee which is around a thousand validator stand with extremely high probability at least one half of the validator is on it so you lose a little bit of honesty going from the pool to the community but it's not too bad and then because you have this fresh hold in the cross link you can make the fresh hold large enough and so in this case you make it greater than one half and then you have a guarantee

with a very high probability that at least one if you do reach the threshold at least one of the voters will be honest and so being honest means that you've actually have downloaded the data on your computer and if someone requested from you your your share it with them so the data is available to the whole network okay but there is one problem with cross links and it's it's due to this kind of misalignment of incentives so there's two ways to go about cross links so the the honest way is basically you have this chunk of data which is quite large and you need to go ahead and download it then only after

downloading it you you sign your attestation and then because you did all this work we will reward you in the protocol and this is kind of the approach why you need to do all this work and you know you have this man that's sweating but then there's the other approach which is kind of cheating which is you have other people that are making votes these data stations and you just kind of look at what what other people are doing and you kind of copy what you're doing so it's kind of a copycat strategy and seeing what other people are voting on is very cheap because these votes are very succinct

and so you can just follow the crowd and still get the rewards and this is basically the light mode approach which is the lazy approach and it's kind of like SPV mining in Bitcoin and it's it's kind of bad because if you have an attacker which is not necessarily that's huge but like significant they can they can vote for an unavailable crosslink and then all the lazy people will pile on and then you'll reach the threshold and then you have an unavailable crosslink so that's that's kind of bad so one of the key idea is that in addition to signing the data you're

going to tag on this proof of custody which is this kind of really cool construction which is just you're going to tag on just one single bit either 0 or 1 in your attestation and that is going to prevent or disincentivize people to be lazy because if people are lazy and they don't download data then with probability 1/2 they're going to mess up the proof of custody and so they're gonna get slashed so as a now now as a validator if you want to be lazy what are you gaining you're just gaining a little bit of bandwidth it's a very minimal gain but what do you stand to lose you stand to lose your deposit

with with with high probability and what we've done basically here is that we've upgraded the security assumption of cross-links which was honest majority to something closer to rational majority so there's this kind of this is the the honest people and then there's the rational or the kind of a to extremes and there's there's all sorts of things that go in between honesty and rationality so one one of the things in the gap is going to be laziness and that's specifically what we're targeting I mean there's other things that can happen like illusion and bribing which we're not addressing here but laziness

is what we are addressing ok and same thing here with extremely high probability you're gonna have at least one on this on this bit lazy validator and they're gonna actually do the work because of the proof of custody ok tom challenges these are very easy so let's assume that you've signed an attestation so you've committed to the fact that you've downloaded some data and you know the data someone might want to make query about the data and they say just give me this chunk at random and the the

response needs to be fed or on the beacon chain so everyone is is is aware that you can chain and the beacon chain itself is available through this brute force approach of everyone that just downloading it and the reason why we have a small chunk as opposed to the whole data is because the beacon chain has very limited bandwidth and so we can only afford to put these small chunks and then this in addition to the small chunk you also have a merkel proof that the chunk has indeed match the the cross link and the the index basically the the location in the data and that has been that was in the challenge okay so now to the the most interesting bit

which is the the custody bit game so how do we basically enhance these data stations by adding one single bit in such a way that if you don't download the data you will be caught half of the time so just to reframe the the problem again slightly more exactly so you have the data you have these the data routes the signature both form an attestation and you want to basically have a so-called custody bit which is a basically a crypto economic construction so it's not a cryptographic thing is not like you know cryptographically with very high probability that that person has

downloaded the data you you basically weekend at a little bit and say that we probably see one half if they got it wrong sorry probably one half they will only get it right they only get the custody bit right we've probably see one half and they'll get it wrong with probability one half and we will know about this at some point in the future in the in the near future okay so just a quick note about why one one one single bit is kind of a very nice property to have and the reason is really related to aggregation so BLS aggregation is signature aggregation techniques technique which works extremely well

when you're aggregating the same the same message so the the verification cost technically is like going to be like one pairing per message and doesn't matter how many people are assigning it you still have this this basic cost but as soon as you have multiple multiple messages being signed you need to pay these multiple pairings and when you only have two types of messages you know attestation plus the bit 1 attestation plus 2 B 2 then you can just gave them separately and your verification cost only doubled and it's it's still it's still marginal so basically in the in the optimistic case where people get the proof of the custody bet correct then there's there's

very little overhead to the beacon chain and if people are you know are doing very stupid things like not downloading the data but still participating in the other stations then they'll get caught and there will be a challenge game to basically slash them okay so what is kind of the one of the key ideas in the construction so you have the data and you want to come up with a construction which kind of proves that you and only you have you definitely have the data so one of the ideas is that you introduce the notion of a key which is unique to you as a validator so even though the

data is generic to everyone you have a key that is unique to you and we're going to temporarily attach the value to this key so if you give the key to someone else to some sort of outsourcing service then that outsourcing service can can use the key and take your money so if you don't trust the outsourcing service you really don't want to give them the key or your key okay so we have the data we have this private key and what we do is that we mix the data and the key really really thoroughly so that you know they kind of maximally combined and then once we have this this mix which for example could be the XOR so you have the very long piece of data and

the short key you just XOR every single chunk in the data that's one way of mixing and then once you have this mix you can extract one single random bit so that's going to be using a so-called pseudo-random function the PRF and one way for example to extract a random bit is to take the hash of the mix and take the first bit of the hash it is going to be random and the whole point of this construction is that the only way to compute custody Birds is to have both the data and the key and in particular to have the data so you have downloaded the data and just to to rephrase this no no no possibility visually you have the

validator they have the key but they kind of want to be lazy they wanna outsource the downloading of data to someone else so someone else has the data and unfortunately in order to compute the the custody bit you need to combine the key and the data so there's kind of two ways to combine from this from this set up way number one is to take the data and bring it to the left side well that's kind of defeats the purpose because now the valid data actually has to download the data so they've gained nothing from the outsourcing service and the other option is to send the key to the right side but that's not going to work for the validator because then the

outsourcing service has the key and so they can still you can see all the money up from the validator okay so let's go through like the whole dance in the scheme in the protocol so we have three phases commit reveal and then challenge so commit you commit to having data then you're going to reveal your key and then if the custody bit is wrong you're gonna be slashed so off chain in the commit phase you will generate your key which is going to be unique and deterministic you download the data you complete the bit and then you commit boom that goes on train sometime later you will reveal your key and then once you've revealed the key

basically your custody bit becomes publicly verifiable anyone anywhere in the world who has the data now now also has the key and so they can verify off chain you know does the does the mix as the combination of the key and the data match the custody bit that was in the initial commitment in the attestation and if for some reason it does not match then then you challenge you you go and chain with the data and you say hey we can chain please you know compute this disgusted a bit it's wrong and and please slash slash the validator and in addition to this slashing condition we

have another session condition which I kind of been talking about explicitly which is that if for some reason the key has been given to someone else then you want to have this the slashing condition for leaking the key early before you met before the reveal phase okay now there is one problem with this the scheme here and is that in the worst case if validators have a bad custody bit then the in the challenge the the data is going to be is going to be like the whole cross link data it's going to be all 16 megabits so that's too much data

for the beacon chain the beacon chain can only handle things like on the order of so-called chunks which you know about 5 4 4 4 kilobytes 4000 bits so how do we go from this very large piece of data 16 megabits to for just 4 kilobytes and the trick is to basically take the data and cut it into four thousand chunks each chunk of size four thousand bits and then for each chunk you compute a separate custody bit and then you kind of combine these bits the so-called chunk bits you have 4000 of those into a

final custody bit so if you just ignore the middle bit you still have a custodial PRF so you help still have a scheme which takes the data and produces one bit and guarantees that you have the data but there's this now there's this kind of intermediate thing in the middle and this intermediate thing allows you to challenge very efficiently so if for some reason you disagree on the custody bit then you will publish unchain your version as a challenger of the of the of the intermediate bits and then the original validator that is dead duty to

either while to point out where the Challenger is wrong so that they can come to agreement as to who is wrong and if and if for some reason the Challenger is is not wrong then it will be impossible for the for the original validator to point out an error in the Challenger and one kind of important detail here is basically the the numbers that we've chosen so notice that 4000 is the square root of 16 million and so it turns out that taking the square root is most efficient because the yeah you're gonna have the number of chunks times the size of the chunk is going to be the

size of the original file and the challenge is going to be the sum of these two things and so taking the square root is optimal anyway it's indeed done but yet just to rephrase visually the how the challenge game works the only difference is now in the in the final step in the challenge you provide these intermediates chunk bits and then the risk the validator the original validator has to point out where the the Challenger is wrong if it is wrong and the way they do that is that they provide the data to the beacon chain with the data and the key the beacon chain can compute this intermediate bit and of course the the data is Aventa kated against the

crosslink okay so this is one of my last slides so this whole this whole scheme is i pretty pretty amazing it's very cool that it exists but one of the one of the design considerations for a film 2.0 is to be so-called MPC friendly or friendly just to just to staking pools and things like that so we we want to be able to take the notion of valid data which is kind of a logically a single entity and behind-the-scene kind of off of chain we want to allow users to take this validator and split it up into shares and have you know mmm event logic so

there's two use cases for that one is taking pools so if you if you don't have the minimum amount of if you're required for example 32 E for 64 if for sure you can pull your funds with other people and you each have kind of voting power and proportion to your your stake and then you can set a reasonable threshold within your second pool and and basically have one single validator with multiple users behind it the other use case for being MPC friendly is the idea of distributed staking so you you are a single validator you have the 30 to Eve but you don't want to put all your eggs in a

single machine so what if this machine gets hacked or what if this machine goes offline so what you can do is you can for example have three different machines and you can set up two out of three validation so that if you if you have two of the machines that are online then the system keeps on running and if you have only one at most one machine that gets hacked then your your your your hotkey which is your hot validation key conk attacked ok and in in order to kind of be MPC friendly we need every single part of all the way from 2.0 to

be MPC friendly and this is going to be three different things that are specific to the so the custody bid scheme which makes it tricky but turns out there's these really nice constructions that they'll involve on the one hand BLS signatures so it's you know BLS is very good for these threshold signatures and you can use fresh hold signatures as your your key scheme your secret and we do the same thing for for R and L so you know Rando is a cream it reveal scheme where you could you commit to something and then you reveal your entropy one way to phrase this one once you implement it is you commit with your

BLS pop key and then the way you reveal is by signing a message and because BLS signatures are all unique and deterministic you have a well-defined reveal anyway and the other cool construction is for the PRF so it turns out that this is wonderful like mathematical construction called the lujon symbol and it seems to fit you know exactly our needs so it can take a chunk of bits and it will generate a unique random bit out of it and it's the whole thing is like very MPC friendly I think it's a maybe two or three rounds of communication which is great anyway thank you this was the whole scheme if

you want to read the specs I encourage you there's a there's a draft right now but it's it's pretty good and yeah I also want to thank people who've been working on this back and that's it thank you [Applause]