ZK10: zkCasper: An Accountable Light Client for Ethereum Casper FFG - Seun Lanlege

Transcript

foreign [Music] and I'm the founder of Plato Labs we're like a core team for polka dot describing our implementation of ZK Caspa which is a succinct and accountable Lifeline protocol for Casper FFG um so I guess the first question would be why not just use the so-called sync committee if you're familiar with the ethereum consensus protocol a few issues the synch Community cannot be slashed I mean today anyways and in our opinion this violates the safety guarantees of any sort of proof of stake

protocol if you recall uh sort of the safety guarantees of approval State protocol is predicated on the ability to be slashed if you try to double Vote or double sign Echo vacation all these different words for the same thing also even if they could be slashed this amount at stake is just so low it's basically pointless I mean you have like what 27k eth around 30 million uh say I had a bridge that had over 100 million locked secured by the signatures of this sync committee it's a very profitable hacking in my opinion and even more so we're seeing the rise of Mev and uh sort of Mev use cases I think one of the most important mov use cases would be for actually node

collusion so you can imagine I'm running MV boost and it says look if anyone who's uh who's also running MVD boost is also in the sync committee and there's a super majority set then I want all of us to fork and sign this fake chain where we just basically would throw all the funds on any bridges are dependent on our signatures um so yeah I write more of course about this more extensively in the uh our official research blog and so given all these problems we've decided to tackle just verifying the cast FFG consensus proofs directly just a fun meme because I think it was Barb benheimer during the time of course building a synchronity Lifeline is pretty easy but when you start looking at Cost bath FG you're dealing with what

800 850k valuator sets size it's a bit it's a bit much um so let's just quickly review Casper FFG currently I think on the beacon chain website you can find that there's like 800k values actively values in the chain even though this prop only like 10K nodes so it's just like multiple nodes or there's multiple Keys per node something going on there but it will degrade the network to sort of pass around a single consensus message you know sort of round robin fashion in it we just add our signature to that that doesn't scale and so what you have is uh the protocol splits up all the entire set into this attestation committees uh Max size for the attestation committee is about 2048 so you would probably have

like 500 attestation communities at any point in time and each attestation Committee just basically signs this attestation message with their own BLS key um it's the case that every attestation Community has a different message to sign because they also sign what is the committee index so no two messages will be the same so you can also aggregate that as well uh but of course because they're using BLS it's the case that the signatures can be aggregated as well as the public keys but you know if we just aggregated the signatures aggregated the public Keys we don't actually know who are the constituent public keys in the aggregate so we don't have accountability so you can't just do this naively on chain um so we'll just look at more of the

implementation details of cosm FFG the protocol tracks all of the validators in the so-called value registry and um it's the case that values are never removed from this registry once you're added you're there forever um and if you maybe exit the queue or you you know get slashed you just have your metadata updated that says you're no longer a part of the set and of course the new visors just keep getting added to the set and that list just grows on indefinitely hopefully that gets bounded at some point uh with uh of course your single stuff analogy on the horizon now this registry is also an SSC object for those of us who are familiar with the consensus specs it's just a new way to store data that preserves the ability to miracleize this data so it's the case that we can always get Merkle

proofs for any values or in the set this will be important later on but the last thing I'll note on Casper FFG is that the Casper FFG vote is the so-called uh Tuple of epoch boundaries so the so-called source and the target Epoch boundaries and a more visual explanation for this would be to see this let's say this is the Genesis that's sort of finalized by the protocol implicitly this would be finalized this would be justified well and then I guess well this will be justified to be finalized and it's been finalized and then of course the blocks they grow from that point on all right so refresher on BLS just before we start diving deep into the protocol itself

um VLS says hey look if you have some signatures it's the case that they are aggregatable you know just take you know elliptic curve Point Edition and it's the same thing for the public keys right you can aggregate the public keys and then you just do a single parent check and that will verify uh this all these signatures in a single parent check of course this is the case that your your public Keys have all signed a single message uh if you have distinct messages then is the case you have to take a sum of the pairings um some classic same same thing going on here but in a more advanced case you now have what are multi signatures so this is actually an already aggregated public key and you have already aggregated signatures and then you're still sort of

summing that up and they're all signing over distinct messages but you can still verify the signatures in this way so you can imagine uh this aggregated public key are the sort of committee public Keys these signatures are signing over their own attestation messages and this is kind of how we would verify these signatures uh you could also do this in a snark although I don't know how feasible that would be because that would be close to like a thousand pairings in a single snark uh hopefully folding helps there a bit so take stick back the most expensive part in cast by 50 is actually in handling the public Keys you have like what 800k public keys to verify the verifier has to be aware of these public Keys just because of how BLS Works

um you would have to take the sum of those public keys if you wanted to amortize the costs of the of the attestation message to a single pairing but yeah what if what if we could introduce a snark proof that sort of attests to the validity in quotes of the aggregate public key that says hey look all of these all of the Constitutional Republicans of this aggregate was correctly computed from a set the verify news so in the scheme the verify just only knows a commitment to all of the values in the valid or registry and they are presented with the aggregated public keys of each attestation committee and uh sort of bit lists that says look all of these public Keys correspond to these bit lists uh these positions in the

registry we need a bit list for accountability otherwise we don't know who signed in the committee and it's the case that well we can't slash people if they double sign which goes back to the problem the synchronity had so I won't get too technical about the APK proof schemes actually this is worked on by web3 Foundation researchers and it's the case that Alice there already presented the scheme himself at a previous edition of ZK Summit but I'll just summarize what's going on there um the scheme is built over you know the so-called half cycles of elliptic Curves in the sense that you can embed what is the base field of a curve into the scalar field of another curve this you know useful in snark recursion and all that fun stuff but in this case we're just dealing with points that describe

uh public Keys which are elliptical points themselves and we embed those points inside of the scalar field of another of another curve and then we can start to do commitments in that curve and opening proofs and uh you know classic snark stuff um so the next thing is we're basically doing elliptic curve point a fine addition now we use a fine because other coordinate systems would have you know three points and then we now have more than two commitments that we have to open the less commitments to open the better um and it also supports representing the field elements or the bitless as either a field element or in the binary representation of the field Elements which uses a more complicated uh polynomial commitment but that's uh I won't get into that as well also the

snark scheme doesn't do permutation checks so there's no wiring whatsoever we maintain what is the so-called accumulator and I can show you visually what that looks like you have this you know classic plunk Sudoku you have the initial State that's chosen part of the scheme it's a property of the scheme um and if this bit is set to one then it's the case that we have to take that this accumulator this or this initial accumulator and uh add it to the whatever values there and we get this value and if it's the case this is zero then we don't really add anything we just copy it over right and so this way we only add uh points that are described by our bit list and you can imagine that this set this X Y is a list of the uh the values that we're interested in and so we have a

commitment to that list so yeah we get into more technical Parts about the spec in the original paper that webp Foundation researchers presented they were actually using the 377 761 cycle it's the case that these Cycles actually have a highly two attic uh structure in the field which allows you to use the classic Radix 2 fft you know we all know and love the Radix 2 fft but if you factor the uh the outer curve for the 381 curve which is 767. you get this very very ugly big primes not very friendly to my Radix 2 fft so we have to switch gears and use a different kind of fft algorithm um so it's the case that the Radix 250

is a class is a special case of the Coulee 2K fft uh and the cool effect is just a way for you to sort of decompose a kind of Matrix factorization you can decompose a DFT into two smaller dfts if the DFC itself is of a composite size um and then if you you know if you can reapply this recursively then you get back your Radix 2 which gives you the two log n complexity but it's also the case that it can be combined with other fft algorithms for instance we have Radar's algorithm which is useful for DFCS of prime length uh but there's also all the fun stuff like window grad um good Thomas you know if you're interested it's fun stuff all right so let's get to the meat of ZK Casper it's the case that we need to initialize the verifier with a commitment to all of the

validators in the valid or registry you can think of it you know it's a classic like client you need to initialize the state of the like line and then you can just continually update from there and also we initialize the verify with a bit list of all of the disabled validators in that commitment so it's the case that some values may have exited they may have been slashed you know whatever so we let the verify know that these values are now inactive so the approval provides what are what's the signature the already aggregated public key of each attestation committee and the attestation message for all of the attestation on committees um and of course a bit list that says which of the public keys in the registry were participating in these public in

this aggregate public keys and then this APK proof that I just described uh which the attests to the validity of of those public keys so the verify performs this very weird thing there that's a logical xor and what that does is if the prover had enabled some of our disabled validators then that operation would remove them from the bit list that they supplied and then we just take a sum of all of the apks that are provided to us and verify them with the APK proof snark if it's the case that the proof I had indeed enabled some disabled valuers then that snark would no longer verify if it's the case that any of those apks are not in our commitment that snark would no longer verify um so you know I leave the soundness

analysis for the snark to to the to Alistair and its talk and now we can just do signature verification right so now we no longer know the individual public keys of the values but we're still able to verify the authenticity of those aggregate public keys exploding to wrap up the session right um I'm just going to quickly run through this one so how does it verify learn of you know values that changes because of course the set isn't static you know values are join the set they leave the set what have you well the attestation some solve contained what are these lmd votes which you know the values are testing what is the latest Block in the chain and the verify can just use the status block with Merkel proofs that I described earlier of the value registry

to add to remove uh you know update their bit list basically of of what they think is the disabled set of validators and you can see that just through this homomorphic uh Edition here and I give a proof of that it's very short proof um yeah so safety and accountability the verify now has sort of zero knowledge of the set but there's still safety through the preservation of slashable data if it's the case that the verify is presented with uh an attestation message that violates the cost by 50 protocol then maybe if they did that on chain and someone else could see that happened on chain and then report them back to ethereum and then get them slashed um and the build list also preserves accountability because we know what you know the individual public keys that

were part of that sort of uh equivocation for the attestation um and of course we uphold safety with the ability to report these slashable offenses if you want you know extended reading I write about this more on our blog as well uh so what are the applications of this first you can have you know fully trust-free Bridges to ethereum with the highest crypto Economic Security it's basically you're running a beacon chain node like prism Lighthouse whatever it's literally running on chain and you have the best security possible often like clients could also benefit from this I know there's Helios by the a16z team you can imagine the sync Community could also perform Eclipse attacks on off-chain like clients in this way the way in the same way they're able to Eclipse unchain like clients so this prevents that from happening in the first place you could

also possibly run this in the browser uh you can imagine uh you participating in the PCP Swan but you just receive very succinct proofs of the attestation so you're not doing all this multiple pairings and having to maintain the full set locally uh yeah that's the end of my talk I'll take any questions all right thanks a lot so we can take maybe one question while the next speaker manush is already setting up any questions thank you for having me yeah thanks a lot [Applause]