ZK9: Biscotti Trustless Light Client Infrastructure for Blockchains – Rahul Maganti (Jump Crypto)

Transcript

foreign [Music] yeah so um it's going to be kind of the topic is sort of similar to the last presentation but I wanted to kind of present something that we've been working on for quite some time um so it's called biscotti we love Italian cookies apparently so um this is basically a trustless light client infrastructure for blockchain so what we're looking at is essentially you know some of the stuff that everybody everybody in this room has been talking about for a while how do we build efficient DK like clients for different blockchains um oh I should mention also this is Joint work with a bunch of folks at Jump crypto over here so all right so we started with ethereum

obviously because I think most most people in the in this room understand why um so I'll just give like kind of like a brief overview of like what why um you know what the consensus protocol for it looks like and what we're trying to actually prove so the altar hard Fork introduced you know this like line specification which allows you know cheap verification of the chains consensus with minimal bookkeeping what that means is basically you have this like sync committee that you know has um a set of 512 validators that are uniformly sub-sampled from the entire set of validators which is around 400 000.

um all right so here are the few components I think that you know that are uh they're in this proof of consensus so we have the BLS Sig verification we have the simple serialize and rlp so simple serialize in rlp are the serialization libraries that eth uses SSE is for the two consensus protocol and rlps for the eth1 there's a few components underneath the Merkel inclusion proofs that you need to do and the shaw function implementations that you need to do all in circuit so take a quick look at this but I'm kind of I'll kind of dive into each one of these components and then we can we can kind of feel free to ask questions on on these as well okay so what does the architecture actually look like so

let's take a really simple example we have a trusted block we have a you know an attested block and we have a finalized block okay so I kind of I wrote These in the order in which like you might think about proving them not necessarily the order in which they actually happen when you're actually running this protocol so let's look down at the at the at the component diagram below so the trusted um in The Trusted stage you're basically doing a bunch of marketable inclusion proofs you have to do the numerical inclusion previous also in the finalized stage but effectively we're doing something that was similar to what you know the ZK tree folks talked about where you're basically doing these inclusion proofs within your circuit and then we also have the BLS signature

verification so I'm gonna I won't delve into the kind of the details of exactly what you need to prove in this because it does get a bit hairy but this is kind of the sort of like keep this basic architecture in your head all right so what does implementation look like um obviously I think a bunch of folks in this room also understand uh kind of what the various brief systems look like in the world um this was kind of our criteria for choosing a proof system we want to you know we want this to work really fast and really well in production so we obviously need fast recursion we don't want um you know address it or necessarily Universal setup we want super fast proof generation you know we want and we want the developer

ergonomics to be really nice and the other thing that we're looking at is kind of community support and interest rate we want to go with the things that people are kind of converging on in the industry like where's the putt going and we want to be there um all right so this is kind of the breakdown of The Primitives that that we we have built in circuit and plonky II so we have SSE rlp do hash functions shot 256 and catrak and then obviously the BLS signature implementations which I'll also dive into which contain a lot of different components including you know the base and scalar Fields the extension Fields doing Haster curve doing the pairing all in circuit so let's talk about the non-native operations for a second so as many of you know plonky2 is written over the

Goldilocks field so this is a 64-bit field um you know it's great for super efficient recursion it's also great for efficient proof generation but it doesn't really support these like non-native field operations that you really need for some of the work that we're doing especially with BLS signature verification so the ECC operations like Point Edition you know whether it be affine or projective you have these Point multiplication affino projective and then you have the these extension towers that you also need to build in so you know we have to build in like the quadratic extension the hortic extension the sextick extension and the 12th degree extension all for doing you know the pairing the Miller Loop and the final exponentiation for the BLS signature verification so all these components didn't exist in blocky 2 and

now they're available the code will be up up soon but these are the kind of the different components that that we had to build in all right so let's Also let's talk about the hash functions for a second so um there's two main hash functions that we need to use shop 256 in the in the rlp case and then the catch a cache function implementations in circuit um I won't delve into the details of like exactly what we did with the hacks function because you know we're going to be talking about this in more depth in a in future you know posts that we'll make but effectively we have a an optimized hash function implementation using like interleaved bit representations uh that make you know doing these computations

in circuit much faster so the high level overview is that if you represent you know a you know a set of bits is like this interleave representation you effectively interleave them with with zeros you can do an and an xor operation in a single sort of Edition instead of relying just on you know doing these separately so um all right okay now let's go into the BLS signature verification so as many of you know also eth2 the E3 beacon block signatures are constructed over BLS 12381 um and the BLS or BLS signature verification algorithm uses a pairing and there's a bunch of different components within the pairing so first with the Miller Loop that contains you know doing things like line add or line

double and then evaluating those um and then but all these operations are kind of in your 12th degree extension um the final exponentiation also requires you know just sort of like simple exponentiation doing like for benius doing like these operations over the 12th degree extension as well and then we also want to check that the signatures are are actually within the the right group so we have to do an efficient like sort of subgroup check using you know there's a few papers out there that we've looked at as well and so this requires you doing like an anamorphism um there's another component with hash the curve which requires a bunch of different components as well so I just kind of wanted to give a sense of like

what the complexity looks like when you're trying to implement BLS like within plancky tier within some of these proof systems um all right so this is the last component that I'm I'm pretty excited by um this is something that we've been working on more recently as a result of working with a bunch of these different proof systems and like you know how do we how do we not use sort of the the syntax of the proof systems directly so that we can actually have a nicer experience using these Brew systems and hopefully we'll make this tooling you know available to other people as well um we're working on a you know sort of like simple embedded DSL within block E2 that evaluates the expressions in your language as in CPU values and also also compiles those same Expressions to in

circuit targets so you can see like right there we you know this is like a super simple expression language you know let's say you have like a you know a constant like big uint you might have a bull you might have like might want to add two things together you might want to multiply two things together um but kind of the the advantages of this is that it sort of like abstracts the semantics of the Builder interface that you have within blocky2 away from like the person that's actually implementing this stuff it also improves the auditability and readability of of these in-circuit programs so every time you do something like Builder dot add and you try to put your operations there you don't need to do that you don't really need to do that anymore you're just sort of just kind of you look at

the paper that you're trying to implement take that stuff and copy it over into plunky two it makes it a lot easier and nicer to use it also improves like the test and validation efficiency and life cycle of your of your program so instead of having to just sort of sit there and say okay I'm gonna write this test and validate against this other Library like I'm I'm I can write like 50 tests you know in a few in a few minutes as opposed to just a single test that takes an hour because you're just you know playing with bit strings all day so the other thing that I think is super exciting about this is that we can sort of encode proof recursion directly into this DSL and Abstract that away from the implementer as well so instead of having to write these generators that are

allowing you to do your proof recursion you can just you can sort of just encode that in the in the compilation step so you just say okay I would like to add recursion at these lines at these levels and at this level of granularity and it should just do it for you um and I think that that's going to be very exciting especially as as you know people start using you know using these different libraries want to do proof recursion super efficiently but don't really want to think about like what are the real intricacies of using these different like tools Okay cool so another thing that that's super exciting about this uh this framework or I guess framework of embedded dsls is like kind of new optimization paradigms right so this is kind of like a more PL term but

hashconzing basically is this idea of like you know abstracting over the semantics of your program and the structure of your Expressions so let's say you have an expression in your program that you've already seen before right instead of just like evaluating the expression again you should just be able to look up that the value right and so this kind of like allows you to do that and this is sort of like a standard sort of trick that's used in PL as well and that's something that we want to bring to the blocky2 ecosystem and so to some of these different pre-systems the other thing that we can do is actually directly encode optimizations at the evaluation evaluation step so instead of just you know adding let's say two in circuit representations together using whatever operator exists within that

Brew system we can just evaluate the addition or whatever operation in CPU and then construct the in-circuit representation from that um another you know example of this is like let's say you're doing skill or multiplication or exponentiation you can just directly encode the most you know an optimal algorithm for doing that right so the naive implementation is like exponential if you use double an ad it's linear effectively right so it kind of reduces the reduces the complexity by an exponential time but you can just directly sort of encode this in the in the evaluation step so every time you use that that function it's already being optimized um yeah so another example of this is like simplifying in circuit conditional so a lot of you have probably come across this canonical example in

circuits where like you have to represent you know both cases of your conditional and and that sort of and then you sort of like add these two cases together and that's not really how you think about programs when you're you know programming in the non sort of like circuit World um and I think this is going to be like something that that people will hopefully find a lot easier to write um all right so what are we trying to do with all these things so let me just summarize so we we worked on a bunch of stuff um related to like sort of like Merkle inclusion proofs you know eat serialization and then kind of doing signature verification of BLS I said why we started with eth but obviously we want to move to other chains as well and so working on you know some of the CK

like client infrastructure for non-evm chains you know ethereum non-etherium chains we want to work on some of the cryptographic Primitives that enable this so like let's say eddsa signature verification or 825519 signature verification for let's say like Cosmos or determic consensus and then we want to work on faster and more optimized proof generation for this stuff so there's a ton of work that was going on in the Z Prize last year especially on fpg acceleration and GPU acceleration I want to take some of this stuff and kind of at least enable some of these perimets to work on on Hardware as well and then again improve developer ergonomics and additional sort of like DSL features so that people when they're using these proof systems don't have such a you know horrible time trying to trying to bootstrap into the ecosystem

all right that's it thanks [Applause] um I actually have a question the DSL does it have a name is the is that biscotti so it doesn't have a name but if you have a name of an Italian cookie you'd like to use okay it doesn't have a name yet then no it doesn't yeah okay uh which which like biscotti though is that the larger construction that the name is It's a larger thing okay got it are there any other questions about this oh we have a few questions that's perfect I think we have time oh yeah I was wondering if you could

comment a bit on kind of like the performance especially compared to some other uh sync Community implications like uh succinct like how many gates like entification things like that yeah so we're we're not releasing any numbers right now um but we will soon we just don't want to like talk about the performance yet until we have the full thing sort of like where you can like review the code and look at it so um hey um thanks thank you very much for the talk I'm just curious what was the motivation for starting this project yeah um there's a few motivations I think um

generally speaking like client infrastructure is sort of like lacking within the ecosystem um I think in a really efficient way to do this obviously is using ZK um for a long time it didn't really seem like that practical to do this especially because you need Super efficient proof generation there's a lot of other applications for example you know Bridges crashing messaging protocols ZK oracles like a lot of this stuff requires some of this infrastructure and like so you know a jump we try to contribute to a lot of infrastructure so this is kind of this is the motivation for that there's one more here hey thanks for the nice talk um so you're building decal light Prime proofs for the Altair sync committee not

an alternative to it right yeah this is for the Sinker mini okay in particular yeah and specifically for Bridges sorry could you say that specifically for Bridges no this is this is sort of just generally like okay this is general like like client infra yeah but so for Bridges um the the problem that you'll that you've got is um so the synch committee can post like can sign the correct block on chain and consign um if I didn't block for like the for the light lines and it doesn't have any way to prevent that yeah so the sync committee there's no way to prevent that um this initial implementation uses its in committee we plan to expand it to the full validator set okay grants

there's another question over here and if there are any other questions thank you for the talk have you thought about the business models and whether you are looking at this as a infrastructure public infrastructure or more of a proprietary software yeah we have no plans so far in terms of like there's no business model attached to this this is just sort of like stuff we've built so you know there's one over here there if there are any other questions just put your hands up now so I can you have one do you have one okay yes I wanted to clarify right now it's

not available to kind of to play it is it uh uh really it's not released right now I understand but is it available to dig into it to a deeper somewhere or not yeah so we'll release the the code soon um it'll be up on GitHub and you can you can look at it so okay we just haven't like released it yet they can follow now to find out updates just on jump yeah did you say that again there can follow updates on this topic I don't know some do have some specific oh yeah check out our Twitter okay okay there's one here and then one there or then one there and

then one there and then I think we wrap up because I think yeah we're kind of at times the first I have a quick question why make the DSL and rust or like this like quasi layer on top of rust instead of a language that has like nicer meta programming abilities yeah one thing well one reason is that because well we're already working with monkey T we're already working with rest and this is more of like we it started out as more of like an internal tool like we just were very frustrated with using the syntax that exists already and so we said why not just do this um I think the other thing is that there are already a lot of you know sort of like ZK dsls that exist and are out there in the ecosystem and we're not

necessarily trying to compete with them we're just trying to provide better Dev for ergonomics in a particular way right and for a particular proof system in a you know particular language so there's a question over here hey are you familiar with the Unison programming language I am not okay I wondered if you'd take an inspiration from it because you reminded me of what you were talking about Unison it's a functional programming language where the names of functions are determined by a hash of the kind of combinator Primitives that go into it and there's all kinds of benefits that you get out of that you're probably discovering some of them with what you're doing so it might be worth looking into they've done they've been working on this for a lot of years they've come up with a lot of of cool things you can do once you're once

you're in that kind of world cool take a look okay we have one back there and then I think we'll wrap up on that I think if that's okay I guess after if they have more questions they can chat with you directly right perfect have you done sort of benchmarking on how long it would take you to prove 400 000 signatures right now we haven't done a benchmark on a hundred thousand signatures but do you think it's plausible in Under 12 minutes um potentially I mean I I have a decent idea of like what kind of Hardware you'd need to do that um I don't think you need to when you when you say prove you know on the order of 100 000 signatures like that's not really what you're doing because you

have like in the ethereum protocol you have like a you know a set of like aggregate signatures that you need to prove and so it's mostly just doing a bunch of aggregation and then doing a bunch of you know let's say like a few hundred you know signature verifications so um that I think is probably feasible but you know no comment on on the other part all right thank you so much Rose and thank you all for these questions [Applause]