FOCIL Breakout #8

Transcript

[Music] Recording in progress. Hi everyone. Uh welcome to for soul breakout session number eight. Uh which is going to be a bit special because yeah I I think like the last couple of times we had a bit more time than was than what was planned to uh to discuss implementation. So I think it would be nice to also have like one or maybe two presentations um for fossil breakout sessions as well so we can learn about everything that's been um sort of like top of mind around fossil for for the the past weeks I guess. Um

so yeah if also anyone has like ideas about like guests or cool people to invite uh to present their their work around fossil or maybe even more generally censorship resistance it would be good um reach out to me or to to yeah maybe to me and then we can set it up. So today we don't have just one but we have two presentations. um if we have like a lot of time left after the two presentations I will also present something as well on um on fossil and and statelessness but uh if we don't and that will probably be the case then um I will leave some time for

discussing uh implementation progress and and see where everyone is at um but yeah I don't want to to take more time than this so maybe let's jump And first we have Julian who is a researcher at the EF in the Rick team which is the also my team and that uh is going to present um includ uh I think which is very exciting cuz yeah for me the meme is like bring your own transaction and like make sure it can get included which is very nice and and can be thought of as like a cool

extension of fossil for the future. Um, it's not totally fleshed out if I understand like it's like it will need to be studied a bit more, but it's it's like super nice to have like new ideas coming on where can go. Um, so yeah, Julian, you're up. Yeah, thanks for the introduction. Let me share my screen there. I think you can see it now, right? Yep. Nice. Okay. So, hi everyone. Um, I'd like to present includive mechanism for Fossil. So, Fossil is currently unincentivized as many of you would know. Uh, that means that includers are not rewarded for their

participation and designing an incentive mechanism is challenging for a number of reasons. First, it's difficult to get the incentives right. Designers can either focus on the long run to get a good set of includers or they can focus on the short run to obtain a high cost of censorship. Secondly, incentive mechanisms are costly to implement. Uh that means that they require core of attention to implement and potentially requires to store the inclusion list on chain which would be difficult for syncing as well. Uh and finally rewarding includers for their individual participation. So how well they made their own inclusion list is tricky to reconcile with privacy preserving variations of fossil like zuk fossil that Benedict will present after me. Uh because you need to reward people for

their individual contributions. So you need to know basically what they contributed. Um it hasn't been for a lack of efforts that we haven't been able to solve all these problems jointly. There's been quite a lot of work on this. So for example also which you can see in a very very tiny version here is a collaboration led by Sarish from Duke University. Uh and it's a very clever mechanism. Tom has worked on this a bunch and he introduced the includer fees here as well. Uh and then we have a working project project collaboration with Akatagini from Nethermind which is potentially promising as well but here I'd like to present the alternative which is includ takes a very different route than all of these previous incentive mechanisms. Uh

it doesn't aim to make a long-term set of in of effective includers. Instead it allows people to become an includer themselves. Um it's very easy to implement uh and it's compatible with privacy perversing uh preserving variations of fossil and the key intuition is that it relies on exogenous incentives. So that means that those people that want uh their own transactions included and if their transactions might be censored they are incentivized themselves to create a good inclusionist because they simply want their transaction to be included. So there is no need for additional rewards uh next to that.

So how it works is the following. There are three steps. Step one is the includer auction which is where people bid for the rights to become an includer. Step two is the auction settlement. So that basically means take all of the bids and find who are the winners of the auction. And step three is fossil and so it's basically exactly the same as fossil works now. So includ only is only about appointing the includers and it's not so much about how inclusionists are made, how they are propagated or how they're enforced. So the nice thing about includ select is that a large part of it can work on the execution layer even via a smart contract. That is because the people that are bidding to become an includer in includ select don't have to be stage validators. Basically what they need to do is they need to have some for example

on execution layer uh and send their bid as a normal transaction and the auction settlements can be done via a smart contract and that's also a hint on why it's quite easy to implement because it doesn't need that much uh core dev attention in in that sense. And then the last part also uh relies mainly on the consensus layer. But of course there are also execution layer parts about that. Uh but for the purposes of this presentation I'd like to contain that to the consensus layer. Uh so the first step in these is the included auction which uh which works mostly on the execution layer. So consider three people Alice, Bob and Charlie. They have uh they have their bids which are the form bid which is an amount. So let's say one ETH byes how much how many bytes they want to um get

for their included because remember that in fossil space is measured in bytes and not in gas units. So people bid for the right to create an inclusion list worth let's say uh this many bytes. Uh and then finally the the includer ID ID which is basically the the validator key. Uh so which validator or or person will be sending um the inclusionist of the network and who should people listen to basically. Um so what people do is they broadcast their bid uh and it should be included in the block. Uh the funny thing here is that we actually leverage fossil again. So people are bidding for the right to be an included in block n. Uh so what they do is they submit their transactions in block n minus one. It should be included and

either it's included via fossil. Um and then we move to step two which is the auction settlement. Uh the first part happens on the execution layer. So there is a a smart contract that runs a knapsack allocation uh which basically says uh order transaction order bids by how much they pay per per bite until there are no bytes left and fossil has a total amount of bytes allocated to it. Um so you can bally order them uh yeah like that. So let's assume that Alice bids the most per by Bob the second most and Charlie uh the last. What could happen then uh is that um some of these bytes are allocated via the execution layer. So for example, Alice and Bob are

allocated their bytes and Charlie isn't. And then potentially there is also some uh randomly selected includers via the consensus layer. And these two can be mixed and mingled a little. Uh so for example what you could do is you could say okay well there half of the includers can be selected randomly via a consensus layer like normal validators to ensure fossil works kind of like we have uh worked on up until now and then you can say the other half could be allocated via the execution layer in the smart contract. You could also so say that everything is allocated via the execution layer in the smart contract.

And if not everything was allocated. So in total there were fewer bytes demanded uh than allocated then we randomly select the leftover byes via the consensus layer. But in total there should be a fixed number of bytes allocated and therefore includers are selected in this second step. Basically what we do then is we move on to the third step which is fossil itself. Uh so remember Alice and Bob were allocated um their their bytes because of how much they bid and they selected one includ ID uh and what happens then in block n is that this includ ID becomes part of the inclusionist committee uh and it sends its inclusion list and that inclusionist probably contains their transaction. The

interesting thing here is that the person with the included ID doesn't actually have to be the same person sending the transaction. So it's kind of like stealth addresses vibes in that sense. And then potentially there are still some randomly selected includers depending on how you structure the mechanism. Again you can say that there must be some uh valid randomly selected proposal. You could also say that if there is any bites left over um then there are some randomly selected. So yeah this step then basically pipes into the fossil mechanism as we know it and nothing changes uh from here on out.

So how it works uh or how its properties work is is the following. So first we'll tackle how it solves the incentives issue. Uh and we we look here at the cost of censorship. So again false uh sorry intutor select tries to make a high cost of censorship uh which is the minimum um cost an adversary would have to pay in order to censor a transaction and it's based on a paper um from Elijah Fox Mash PI and Mesnik that formalizes this cost of censorship and here we normalize it and normalize means divide by uh the fee that the censored user is willing to pay but you don't have to care so much about the specifics here basically the intuition is that if someone wants to censor

someone from becoming an includer in includ select what they have to do is they have to buy all of the bytes whereas the person that wants to send their transaction the person that's being censored only needs to pay for the the censored amounts of bytes basically uh and because uh one transaction is likely not to be all of the bytes of fossil um this fraction is likely to be larger than one meaning that the cost of censorship are higher than the cost of inclusion and now you might think that it's also nice that people have to bid in this auction uh because you want it to be free basically for users to to get censorship resistance and I'm going to tell you something that might sound very counterintuitive but in principle the cost of inclusion here is zero as well so even though we have a higher cost of

censorship uh than than than zero the cost of inclusion should in principle be zero uh but yeah I I'll try to convince you in the following here and I'd have to say that this holds usually and it holds usually because of the following intuition Ethereum determines the transaction supply. So currently that's about 36 million units of gas. In fossil that translates to some amount of bytes. Uh but by uh 1559 it means that we have a max dash limit and the target dash limit and 1559 sets the base fee such that the transaction demand is on average about the target dash limit which is half of the max dash limit. So on average or usually as I say here which adopts the

terminology of Tim Ruff Garden uh the transaction demand should be uh lower than the transaction supply and now not everyone has to be an includer um because most transactions won't be censored. So but by like normal inclusion by that time being transactions that are just included because they send them to the public mele or or whatever uh the the demand to be an includer is even lower than the transaction demand. So we have that supply transaction supply is larger than transaction demand which is larger than includer demand. And so in total includ smaller than transaction supply and since supply is very much larger than demand the price of it should basically be zero also because the marginal cost of of providing the the included receipt

is zero. That makes sense. Uh and so the auction here is not so much uh meant to incur any cost. the auction is more as the auction works as a deterrent and there are actually no costs of being censored and I see that the slide rendered a bit weirdly uh but yeah that's I think an important thing here the auction is is I would say like a technicality um it doesn't actually matter that much we just have to have it there for if there is someone who's actively trying to censor your transaction because if that's the case then you can out bit them and if someone is actively trying to censor your specific transaction uh which which will be a very hard thing to do Because in the in select mechanism, you can bid basically an anonymously

um and people don't even know which transaction they are censoring. But let's say that they do magically know it somehow. Uh in that case, your cost of inclusion will be positive. It won't be zero. Uh and then we need the option in order to say that the cost of censorship should be higher. But because people know that the cost of censorship will be a lot higher for them and because they can't actually target your specific transaction, uh that's very unlikely to happen. And if that's not if that doesn't happen then your cost of inclusion is zero and the auction works as a deterrent then onto the ease of implementation. Uh so a lot of this works in a in a smart contract. So that's relatively easy to implement compared to uh other consensus layer changes. Uh and what's really nice

about this is it preserves the property of fossil that don't have to be stored on chain. Uh which means that they're not relevant for syncing or they don't bloat the state and stuff like that. uh and that's immediately brings us as well to how it's priv privacy preserving. We don't actually store the ILS on state uh on chain. Uh we don't reward people for their individual contributions. Again, remember the key intuition is that we rely on exogenous incentives. Uh people want their own transaction included. Uh and so since we don't reward people uh expost based on their individual contributions um we immediately preserve privacy uh because we could combine it with something like ZK Fossil.

And then finally I'd like to pitch like the the big picture of this. I see it as every house should have one light client that fetches the state uh from some uh decentralized state provider. uh which means that in principle you could construct your own transaction without trusting anyone. Uh and so this happens the light client crafts uh the transactions. It then grabs a included select seat and again the supply should be vastly larger than the demand. Um so you should have no problem getting your included select seat and then that means that since you're an includer you can trustly insert your own transaction.

Again fossil relies on like this one out of n property and if you are that one you basically have to trust no one else than yourself. And so is you get trustless transaction inclusion which I think is really really cool. Uh yeah so I hope I convinced you guys somewhat of um in select at least being an interesting mechanism. If you have any further questions I'd love to hear them. Uh you can also reach me on telegram and if you want you can scan this uh QR code for the includ select post or look on my mirror. Yes. That's it. Thanks for your attention.

Awesome. Yeah. Thanks a lot. Um are there any questions? I I have some but I will give priority to any other one. Yes. Yeah. Great presentation. So I think like someone could also censor the first part right which that the first option is that for someone to become a includer or to essentially to basically bid and someone could censor your bid. So such that you can't even become an includ. So it's kind of like a recursive problem here that like someone could use the includer to become an includer for the

future slot something like that. Is there like a recursive problem? Yeah. So I say it's recursive. I wouldn't say it's a problem though. I would say the recursiveness is actually really really cool. And so indeed like becoming the includer is somewhat of a sensitive process. Um as I said the the supply should be vastly greater than demand. So I expect if we say includers are selected based on what they bid and if people don't bid then they're randomly selected. Uh what happens then is people will be uh randomly selected and so Fossil will work and since these bids are basically on the execution layer they're just transactions. They're included by Fossil itself which is kind of the recursive thing. Uh but it's definitely a bit of a a sensitive issue.

Uh so perhaps it's something we can look more into but I I I up until now I feel like uh it works kind of cool uh in a cool way that recursiveness. Um I had a small question like okay imagine a world in which you actually have to you want you get your transaction in uh and the cost is not zero because imagine there is quite a lot of censorship and it's um tricky to evaluate like as in individually like as a as a user like I don't really know like you're like I want to include my translation but how much should I pay is a bit like weird. So yeah, I was just wondering it maybe it's a bit stretched

but like in that world like will people be incentivized to just like outsource this to third parties that can price their bits uh like in a in a more sophisticated way and then we lose some of the censorship resistance properties. Yeah. So um first of all I I I would always imagine that there are like some randomly selected consensus uh layer participants that become includers. Uh so you kind of inherit like the the normal fossil sensorship resistance here. Uh so I wouldn't expect us to be in that case. But let's say that's for some reason like everyone in the world wants to target your specific transaction. Uh then it definitely

becomes uh trickier. I think it's it's very hard to design for such a world. Um yeah, I still feel like this is somewhat nicer because like the the theoretical to censorship uh which is somewhat of a nice concept to to pro see how difficult it would be to get your transaction included uh stacks in this way. So first of all people have to censor you from becoming uh a winner in the includ select auction then they have to censor you from getting your transaction included by some other fossil participants and then they have to censor you from being included by the block producer. So in that way it kind of stacks. uh and so I I would imagine the cost of censorship to be higher in this regime than under regular fossil.

Uh but yeah, again it's it's quite a fresh uh mechanism. So I'm happy to have more chats about it. Great. Thanks. Um thanks a lot. Yeah, if anyone has questions, feel free to reach out to Julian. But I think in the interest of time, we can move on to our next presentation which is um made by Benedict. uh and it's the first presentation on on ZK Fossil. Um so yeah, happy to happy to hear it as well. Okay. So can you see my screen?

Yes. Uh maybe maybe I should Yeah, like this. Perfect. Okay, perfect. Good. So yeah, this uh presentation is going to be about CK fossil. So I'm Benedict. I'm from the Ethereum Foundation cryptography research team where I do all kinds of cryptography research. Uh and one thing that I have looked into with George and Tomar is CK Fossil. So uh we wrote an E3 research post about this and I will just use the the time here to present it and to give you a rough overview of what it does and why we want it and and roughly how it works.

And to do that I first want to set the stage. I want to sort of uh get everyone on the same page about how I look at fossil and what are the elements of fossil that are important uh for to understand CK fossil. So let's start with that. So uh and I want to say this is going to be a very simplified picture of fossil. So we have a set of parties and for now for this presentation let's just say these are the validators. Now the first step is that we select randomly this inclusion list property.

And so uh you can think of this as these validators having public keys and based on their public key we do some sort of random election and then everyone knows whether they are in the comedy or not. And uh once this is done they will sort of assemble these inclusion lists and and publish signed inclusion lists. And then we have uh this this uh magical box, our consensus rules that sort of enforce that if uh an inclusion list is signed by a comedy member, then we can sort of force inclusion. And the idea is that if one of these comedy members is honest, then this provides censorship

resistance. And we make sure by this random election and choosing the comedy size correctly that with high probability we have one honest uh comedy man. Okay, so this is the the big sort of the very simplified picture of Fossil. We have these three elements. We have a random election. Then we have uh inclusion lists that are signed by these committee members. And then somehow uh this uh leads to forcing inclusion if if a inclusion list is signed by a comedy member.

Okay. So let's look at this again. We have our validators and we have our inclusion lists. And from what we have seen now, it is pretty clear that the link between inclusion lists and validators is public. So everyone can see this inclusion list has been uh sent and signed by this particular validator. Okay. So we sort of have a public linkability between validators and inclusion lists. And the question where we sort of started with with CK Fossil is whether we can hide these links. So we want to make uh we want to break the validators. And now you may ask why do we want to do that? Well uh one reason

is that if the validators who assemble and sign these inclusion lists if they are publicly known then they are they become a target right you could try to uh do them or or something like that to uh to sense. And another reason is that if if you as a validator know that uh you will be linked to the inclusion list that you published then you will be sort of uh yeah you you will fear that you face consequences for including certain transactions and that will probably lead to you censoring uh transactions.

Okay. So it's a good idea to hide this link. And now that brings me to the goals of CK Fossil. The overall goal is as I said to to hide these links between inclusion lists and validators. Uh but let's make that a bit more explicit. So in terms of security, we have this goal that we make the inclusion lists unlinkable to the validators. But we want even more. We want to even hide the comedy that is selected uh in order to increase the anonymity set. And uh that means we still need some form of comedy election. But this needs to happen in a hidden way under the hood. And even though that happens in a hidden way under the hood, we want that

it's still a fair comedy election and it's unbiased in order that to guarantee that there is still at least one honest party in this randomly elected comedy. And an adversary can sort of not prevent an honest party from getting elected. And it can also not significantly boost its probability of getting elected. And in addition to these security goals, of course, uh we have some real world constraints, right? We don't want this to be just a theoretical thing. This needs to be uh applicable for the Ethereum context. So, of course, it should be efficient. It should be not uh a very complex thing. So, we want to avoid using very complex cryptographic

machinery for example. And ideally, we uh do that with minimal protocol changes. Okay, so that was the goal and that was where we sort of started with this ETH ETH research post and uh we also have some way of uh achieving this of course. So we get CK fossil by using a cryptographic primitive that is very wellnown and a classical primitive that is called a linkable ring signature. Uh so this is a variant of digital signatures and I will explain what it is exactly uh in a minute. Uh but as it is a classical primitive there are classical constructions of it. Um unfortunately it turns out that if you

look at them they are not really well suited for our application because they are just not efficient enough when we have a very very large uh set of participants or or validators. And so what we did in the post is we said okay let's just throw a a very large hammer at it namely CK snarks and we provided an instantiation of linkable ring signatures from CK snarks that should be efficient enough to be used uh in CK fossil. And even though this is currently our best candidate, I still think personally that this is um more of a prototype that sort of shows what kind of properties we want. uh and there

needs to be more research to get a less complex uh solution because if you want to specify uh a CK snark in in the Ethereum spec that's that's going to be quite complex and uh yeah so for the rest of this presentation I just want to focus on this part I want to explain how we what a linkable ring signature scheme is and how we can use it to achieve our goals in CK fossil and for that We start with ring signatures. So think of the following setting. We have a bunch of parties, say n parties. They all have a public key and a secret key. And now we take their public keys and we put them together in

what we call a key ring, which is just a fancy word for the list of their public keys. And now let's say we have one ser I holding its secret key. Then we want that the signer can sign on behalf of the key ring and anyone can verify that but no one will see which signer it actually was. So let's make this more precise. Say there's a message that needs to be signed then the signer can run a signing algorithm generate a signature and this signature can be publicly verified. And in contrast to standard signatures, it will not be verified with respect to the individual public key of the signer, but with

respect to the list of all public keys. And the intuition again is that you can be sure that one of the signers signed, but you don't know which one. Okay. So the security properties here are uh you can only sign if you have one of the secret keys. um but the signature does not reveal which secret key you had or which signer you are. Okay. So this adds a sort of anonymity feature to digital signatures. And now let's see how we can use this to improve the uh anonymity or unlinkability properties of fossil. So this is again the picture from before.

We have this three-step process. We have the random election and we have our comedy that signs inclusion lists and then we enforce inclusion. Now I want to use link uh sorry ring signatures. We are not at linkable ring signatures yet. I want to use ring signatures. So I will take the comedy and let's say after the election happens we sort of make public uh who is in the comedy and then we put their public keys together in this key ring. And now instead of using a standard signature to sign inclusion lists, they would just use a ring signature.

And now if this this rule in the consensus part which says if it's signed by a comedy member, this just becomes if it is signed with respect to the key ring. This is exactly what the ring signature tells you. If it is signed with respect to the key ring, then it must be that one of the comedy members signed it. And then we force inclusion. And because the ring signature scheme is anonymous, you don't know which comedy member actually signed it. So we broke the link between the comedy members and the inclusion lists.

Unfortunately, the comedy is now public and it's not not hidden, right? The the anonymity set that we have in this in this example would be of size three. Whereas our goal was to hide the comedy and make the anonymity set as large as possible. So it should be uh this whole set of validators and this is where linkable ring signatures uh can help us. So this is again the the picture of ring signatures and now linkable ring signatures add another element to that and that is called the key image. So you have uh not only a public key and a secret key, you also have a key image.

And you can think of this key image as being a unique pseudonym of your public key. So how does that work? Well, you generate the key image. When you generate your public key and your secret key and then when you sign, you not only publish the signature, you also publish the key image. And you can only verify this uh in combination. Now the properties that we want are as before you can only sign if you have one of the secret keys and the signature now in combination with the key image does not reveal who you are. It does not reveal the index I. But we want a third property and that is that the key image is unique given the public key. Okay. So this key image is this magical

cryptographic object that is uniquely determined by the public key but it's still not linkable to the public key right because the signature key image pair does not reveal uh the index. Okay. And why is this called a linkable ring signature? This just a side note uh because this key image is uniquely determined by the public key. If you sign twice you will have the same key image there and then people can see that someone signed twice. they can still not see who you are but they see that you signed twice. Okay, this is why it's called linkable ring signature but for us this property will not be that important. The property that is important is that the key image is

unique given the public key. Now let's see how we use this in fossil and this will be actually how CK fossil works. So we start with all parties that we have, all participants, the the validators. And now what we do is we just put all of their public keys in a gigantic key ring. And now because we use linkable ring signatures, these validators also all have key images which as I said are unique pseudonyms of their public key and they keep them to themselves. they don't reveal I have this key image.

Now we do a random election but we do this random election based on the key images and not on the public keys. So remember before I said you can think of it as take the public key and determine whether you are uh elected or not. Here we take the key images and because the key image is uniquely determined by the public key this should be as good as using the public key. You cannot try different key images for example to uh to improve your probability of getting elected uh because the key image is just unique given the public key. So now with that we get a comedy and this comedy is now hidden. So everyone just knows They don't know anything about the

others. Now to publish an inclusion list you just use the linkable ring signature. So you publish the ring signature and the key image and our consensus rule says if the if the inclusion list is signed with respect to the key ring so that means we know one of the validators has signed it and the key image is in the comedy. So then we know it's one of the comedy members. Then we force inclusion. Okay. So why is this anonymous? as well because the uh ring signature and the key image together do not leak the index of who who signed actually. So could be anyone in this gigantic set of

validators and it is a fair uh comedy election because the key images are unique. Okay, so that's the overview of how CK fossil works. Let me uh finish this talk by take yeah by explaining what the next steps are if you really want to make this work and I think they are three-fold. So the first step is uh I said we have this generic construction based on CK snarks. uh we should try to understand the efficiency of that that is then as I said before I'm not entirely

happy with this construction just because CK snacks are very complex object and there are also some security concerns and so there is a a very nice cryptography research question which is can we build these linkable ring signatures in an in a very efficient way uh while avoiding generic CK snarks. Uh as I said there are classical constructions but they are not made for this large set of participants. And then the third question and I think this is very important uh is a legal question. So what are the legal consequences of all of this if we decide to include this in Ethereum? uh we have

to do that right and we need to make sure that there are no legal problems that we face uh because this will be some sort of uh enshrined anonymity on layer 1 and uh of course there are legal consequences we should clearly understand them uh before we decide to implement this and yeah that's all I wanted to say thanks thanks a lot um yeah This was great. Uh it's even for me like having like a rehash of DK fossil and and and the construction is is super nice. I have a question like uh for Okay, I'll let Ka go before then.

Hello. Thank you. Very interesting. Uh I have a question. If if a validator joins uh already running blockchain, uh what happens with the key with this ring signature? Does it change it and and how to check the key image then? Yes, very good question. So I will go back to my slides. This is something that I completely ignored uh uh in the presentation but this is a very important aspect to consider. So let me go to the to the definition of think of the ring signatures. Um yeah so as we see here the the ring signature

works with respect to a fixed key ring. The thing is that the key image is unique given the public key and it does not depend on the key ring. So that means if a new party joins we will have to update the key ring but we will not have to update the key images. And this is good and bad. It is good because well you don't need to recomputee key images and it does not depend on the time whether you are sort of in the comedy or not. Uh but it's also bad because there are implications for the size the effective size of the anonymity set and this is actually something we also need to study. Uh and

I I mean there's there's a very simple example. Let's say you have five people and one of them signs and then four of them go offline and four new people join and then this one guy signs again. Then you clearly know who it is, right? Just because it was the same key image uh but it was sort of the intersection of these two key rings was just size one. Okay. So there is sort of a sort of something that we lose by publishing these key images in terms of the anonymity set. But if we there's a way to update all key images at the same time and then you can sort of uh as a counter measure to to that kind of

problem. Uh however whenever the key ring changes we will have to uh recomp compute some additional information that I just uh hide here in the signature. Um which yeah we will figure out during the benchmarks how expensive that will be and how often you need to do that. Uh and yeah so this is a still a very open kind of question. So what do what do you do when parties join? How often do you change sort of the the key images? uh and uh but in principle this primitive uh says that the key image does not depend on the key ring just the signature of course depends on the key ring uh and uh that's it. Yeah. So I

hope this somewhat answers your question. Yes. Thank you. Great. Um maybe let's take Mark's question and but there is also a question in the in the chat. Uh so maybe async would be good. Hi uh thanks for the presentation. Um so I just had a question about the key images. So you said that the validators would keep this secret, right? But how would you run a random election over it without knowing the key images?

Yeah, very good question. Uh so let's say so there's one way to do it and that is you take the hash of the key image and some random beacon for example taken from randow uh and you check if the you compute this hash you check if the leading three zeros if the leading three bits are zero or something yeah you can you can have that kind of election and now if I have my key image I know whether I'm in the comedy or not but no one else knows it.

And then once I publish this uh inclusion list, then I also publish my key image, right? So everyone can now check whether I'm in the comedy. Okay? So it's kind of a hidden election. But once you decide to reveal yourself, you can convince people that you are in the comedy. But the thing is at that point it will not reveal actually who you are. It will just reveal there is someone who has this key image who is in the comedy. Uh yeah. So I hope that answers right. But would that mean you couldn't have a deterministic committee size?

Right? Because at the moment we have 16 but if it's just based on the number of zeros it could be any number. It's not deterministic then. Okay. All right. Thank you. Awesome. Great. Yeah. I had a a more like global question. Uh let's see. Okay, maybe I'll just ask it. But like it was more about like if if it seems like there are two path like the classical construction, but it's not I mean we haven't found a way to make it efficient yet and then the generic smart path um which is like not great because it's it's hard to like specify it and it's very complex and and taking it into like Ethereum specs is a bit like of a

moonshot. Um, is there like an alternative path? Imagine like even like combining it with like includ like you can do generic snarks out of protocol where like participants are not necessarily like validators uh but just like people that want to become includers and then you know like the generic ZKNs now don't have to be like implemented in like the Ethereum specs because people will come with their own proofs in in in in some ways. So that can be outsourced to like you know prover networks or provers or anything. So it's a yeah it's a bit high level and I'm not sure I'm sure there

are tons of details to figure out but that was a question that popped up. So I think that would be great if we had that but I assume it's very hard to do something like this and one of the reason is that uh we don't need just snarks we need ck snarks right if you are in a setting where you have snarks then often you could just say you just write the uncompressed verification in the spec right and you say okay there the verifying with respect to the snark is is sort By soundness, it's the same, right? But but for the CK snark, we could not just write the the unsnarked verification in the spec because then you leak you leak

essentially who you are. So I I think this is much more challenging than if it were just a snark and not a CK snark. So currently I don't see a solution to that, but of course that would be great. Yeah. to move the snark out of protocol and then that would be much better I guess. Okay. Yeah. Awesome. Thanks uh thanks a lot Benedict and thanks a lot Julian for your presentations. It's great. Um Sophia I think there is a question in in the chat but maybe let's move to implementation things. Just one quick thing before I want to get a vibe check on like uh how people feel about having more presentations like this in the breakout sessions. Um, one, two. Uh, do you guys like it? Do you think it should

be more about like implementation only? Uh, okay. I see a lot of thumbs up. So, that's great. We'll we'll keep doing that. I think it's also like nice to have new ideas come in and and and like keep up with like the state of the the research at the same time. So, that's awesome. Thanks a lot again. And uh now let's maybe move to uh implementation discussions. I think the first thing to celebrate is uh the uh interact between Prism and Loadar. So I'm this is great like uh that we actually reached that point. I'm I'm super happy and thanks for thanks everyone that actually worked on this uh

this past few weeks. Um no I I saw some discussions uh yeah thanks a lot Jiun I saw some discussions on whether we should use an activation epoch or like sort of like real fork. Um so I haven't like followed super closely but maybe some I know like people wanted to discuss it but in a bit more detail this uh in the breakout so maybe that's a good time to to do it. Yeah, I guess on Lighthouse's end, um, if we were to do an activation epoch, it

would be much simpler from like a implementation standpoint. Um, every time we need to add like an like a real fork, a few thousand lines of boiler plate. And yeah, from like previous work like on pure dasation epoch worked pretty well for like uh implementing and simplicity wise. I know someone said uh Nimbus might have trouble with like kind of like this deation epoch stuff. So yeah, that's just I guess my uh my opinion of it, right? I guess I don't understand one thing that is someone can help me understand it is that like

what do we get with the real fork that activation eod doesn't give you here I'm actually curious because there's no change in the block or the state format right so I think activation epoch is all you need so yeah I I guess I'm trying to hear the argument of having a fork so what do you get in a fork that activation pod doesn't get you. So I guess I could quickly iterate on what I already noted on this code. So um from a codebased perspective in loadar we use the fork in a lot of places like when we uh subscribe to new gossip topic we use the fork sequence not like an

epoch um or how we call the engine API uh constants and stuff like this. Also, I looked at our spec test iterator and it's all based on the fork. So, I'm not like let's assume we have sec static tests. I guess this is an simple example. How would you like does your spec test iterator work with if you just use a fork or uh if you use a epoch? Yeah, I believe so. Okay. So, I think I understand it better now. So, when you say fort, you mean a different fort version. Is that right? Or is that something else?

Yeah. Like or just there like use the fork as a name space. Like if you look at how the spec is structured, they also use the fork there, right? Yeah. Yeah. Yeah. That's fine. I think we can do that in prison pretty easy, right? I I think we can just essentially reuse the same block and the same state type but use the fossil fork number instead of the fulu or the elra for number. So I think yeah I think that's the right thing to do. But yeah I guess my comment was like I was against copy and pasting something uh just name it um EIP7805 but without any change but I think here the change is just a fork version which we could just um yeah let me think about

how to do this. I think there is a way to do it in prism that's pretty easily. So okay I guess I understand the problem now. problem is that you want a different fork version that's 7805 specific. I got it. Yeah, I think either way uh in loadar we can make it work. Uh as I noted, I think if we just use the same fork version as Electra, then our fork digest will be the same even if you just use an epoch, right? So I think but I do think the right thing to do is to use the fork version. I think because you want to upgrade from Electra to Fulu to 7805, right? And this wouldn't work

if you use the same fork version. That's kind of weird. But that's the argument for using the ebook now or Yeah. Yeah. Yeah. Yeah. So now I understand it better now. Yeah. Yeah. So I think for version is the right thing to do. But um yeah, I need to look at prism or I think Jing who may have started looking at it already like how to do this nicely. Yeah, I think we Yeah, go ahead. Yeah, Chess brought this up with Nimbus because I heard they even have issues with the BO and this only touches like some list limits right on recasp and stuff and for fossil you have completely new containers and uh I I would guess they have a lot of issues. I'm not sure

if someone from Nimbus is here. Um but even in pure does there is no change in the block nor the state today as it is. And um yeah and then we also don't copy. So so if it works in Paso I just I I just need to study how people do it in pure dust. Well, well, on pure now they're they're built on top of Fulu, but beforehand they were just using an activation epoch. And I guess like the issue with Lighthouse is once we upgrade to like a new fork, you know, all like the topics change and bunch of other stuff happens. And without that couple thousand lines of boiler plate

boiler plate that I was um mentioning um we have to kind of like hack in this new fork version that we're talking about and adding like a a fake EIP785 fork into the codebase. Um it can happen. It's just yeah I don't know from our end it's just a headache I guess. Okay. Hard for me for to get like a consenses here. Like it feels like people are still a bit split but trend tending towards an activation apart instead.

Yeah. Uh yeah, I mean if you guys are if you guys are already interropping, I don't want to like ruin the momentum or whatever. Um I just wanted to mention it and I think in the future it'd be nice to always try to consider an activation epoch first because it's just a lot simpler. And like I said for purees, um they were able to interop and create proof of concepts pretty quickly with that like paradigm. But we don't want to do that here. That's fine.

Yeah, I think from loadster side we can model it internally as a fork as we do right now. Uh and just not add or update the fork version and then I think it should interrupt still. I guess that's the only change we would need to do. All right. So trending towards unique for version pending like more difficulties I guess. But yeah, it would be good to hear someone from Limbus, I guess. Okay, I can definitely I can reach out.

I mean, I I don't know anyone from there, but like I can I can actually try if you guys I know. Did someone say that you they actually reached out already? Someone from Neimas reached out to me like uh I don't know like a month ago. So I can ask him again. Okay, perfect. Okay, that sounds great. Cool. Um, yeah, we don't have that much time left, but I guess uh does anyone have other like issues or blockers or things they want to find for for you guys?

What's uh okay maybe one question I have is like what's uh the progress on the next interrupt like uh is lighthouse having difficulties or is it is it just like progressing nicely nicely and uh yeah on the lighthouse side um we just need to implement the like unique work version and then we'll be able to start um trying interop. So that's what I'm working on right now. Awesome. Okay, great. That that sounds that sounds great. Um any other updates for for other clients or Yeah, I can give an update from Teu. Um

actually I started interoping with load and prism. Um yeah, it works pretty well. I'm just having an issue with Dora for some reason which is crashing and um yeah from in tech actually we we have also some boiler plate code to add when we have a feature fork uh but that's already done and um so yeah I personally would prefer uh keeping it like that and not going back to the um um epoch um uh transition like so yeah I'm not sure about that that would mean uh that we need to do some uh to revert

some code and do some changes so yeah okay cool yeah great thanks um I mean yeah that's uh that's awesome uh any other I mean yeah even looking at the jet I think Justin also mentioned he be in favor of a unique for version. Um, so it sounds like we're probably going to keep it that way. U if Nimbus also like it will also work for them, but I haven't heard from from them. I don't even know if they're working on on fossil. Are they?

They aren't started as far as I know. Um but I will ask again. Yeah. Okay. Great. Okay. Sounds good. Perfect. Thanks. Um okay. Yeah. For Nethermind just kind of improving the code and working on some review comments. Um I I also swapped to doing this unique fork um based on so built on top of Peterra. So is that matching what other clients are doing which are interropping at the moment or Yeah. So, uh I opened a PR to Ethereum Genesis generator to support uh EIP7805

fork timestamp so that E can use it to determine whether the EIP785 fork is activated. So when I tested it locally with get prototype, it works well but the PR hasn't marked it yet. But I will let people know once it's merged. So currently interrupt is just like uh it work with the IP7805 fork in the CL. So uh we are using the E that doesn't check any fork version.

Uh so it's just like a hacky version. Uh we wanted to I guess we wanted to just see if CL can interrupt. But in the future when we have this genesis generator then of course we want to make sure our e is ready and make sure it uses eb7805 fork as well. So yeah. Okay. Sorry I didn't quite understand. So what are you doing currently then? You don't have a custom fork. So currently it when an engine API like uh like like fork choice v3 or new payload v5 is called it doesn't check any fork version like

whether it is in Osaka or in EIP75 or in prag or whatn not so it just let CL call whatever they want but in the right say you should check if current fork is EIP785. So I just updated get prototype to reflect this change. So you might want to check the PR. Uh but if you do that now then it will break because currently curtosis doesn't say yeah 7805 time stamp but it I guess it will be merged in soon. So yeah, maybe you want to wait like one or two days or if you really want I can make a u uh the I can upload

the EM genesis generator docker image so that you can use it for your local testing. Okay, thank you. I think I understand. Maybe we can uh discuss more as good. Awesome. Yeah. Um let's let's do it and actually discuss it more. Acing thanks uh everyone for coming and sharing progress and and and for the presentations. I thought it was nice and u yeah let's see you all on online.

Bye-bye. Thank you. Cheers. Bye.