Encrypt the Mempool Call #7

Transcript

Justin Florentine: Hi, Anders. I just realized that the calendar has the wrong invite on it. Again. This bot is very… Troublesome.

Anthony: Hello!

Justin Florentine: Hi, Anthony.

Anthony: Hey guys, how's it going?

Justin Florentine: It's okay.

Anthony: Sounds good! Wow. You guys, watch any of the football matches?

Justin Florentine: I did not…

Anthony: Yeah, I didn't get any, unfortunately, as well. Unfortunately, in Singapore, they play at, very early in the morning, like, 3-4am, so… But, I was… But if I was in the US, I would be very tempted to go.

Justin Florentine: Hey, Loring, hey Mercy.

Loring: Hey, everyone.

Anthony: Dale.

Justin Florentine: Jannik, excellent, excellent, excellent, good, good, good. Alright, let's give people some time to trickle in. Apologies if you went to the Zoom invite on the calendar and were disappointed. The bot really is… Yeah. It insists on, maintaining its calendar. Anywho, yeah, so this is being recorded. We have a little bit of an agenda today. We're gonna be doing some brainstorming. Thinking about key reveal optionality. How we can eliminate that. there was a paper, that I was looking at. It's from November of last year or so, maybe a little earlier than that. Titled Silent One-Shot Threshold Encryption. A link to that is included in the agenda. Here, I'll post a link to the agenda in chat for everybody.

Okay? And, I think, Jannik, you had an idea that you wanted to float as well. So we'll make sure that we do have some time for that. So, just to reiterate, The first link in the agenda is a link to Gottfried's paper, or, you know, ETH research post on, specifically the key reveal optionality portion of his critique of Lucid. For those of you that are familiar with the strawmap, you may have noticed that Encrypted Mempool has been pushed back on it, and this optionality is one of the major reasons why. Currently in Lucid, we take a market approach to deterring people from withholding keys. And that may not be strong enough, considering how widely MEV payoffs can fluctuate. So…

We want to kind of take a little bit of a pivot, a little bit of a revisit of Lucid, and try to figure out, well, what are… Some ways that we can maybe enshrine key reveal a little bit more in the protocol, as opposed to leaving it up to the senders or a sender-selected key provider to reveal. Any questions on that? Okay. Did anybody have a chance to look at the silent one-shot threshold Encryption paper? Okay. I am not a cryptographer by trade, so I, you know, I don't want to speak as an authority on it. I understand maybe about a third of it. But I understand enough to be dangerous, and so I took that and

Wanted to consider how we could maybe use that as a threshold encryption approach. So, the idea is… let me just pull my notes up here to make sure that… Yeah, great. So the idea is that instead of allowing users or key providers to reveal their key, there's something enshrined in the protocol that will reveal it, and whether they want to reveal it or not, you remove the option. And the way that this would work… Via the paper, is that A user could generate a key, a key pair, rather, right? And they could encrypt the private half of that key towards a random sample of all of the validators. And what would then happen is, using Lucid as it stands, after commitment.

The random sample would then reveal that key, and the builder would be able to use it to decrypt the transaction and include it as a build. The underlying techniques for this carry with it a couple of different problems. I think the biggest one is that the ciphertext size balloons up. And so, right now I'm currently kicking around ideas, and I say me, and I actually mean me just kind of talking to different AIs and other cryptographers and things like that, like I said. I'm not an expert on this stuff. But were we to take an approach that used a threshold encryption, we're kind of trading problems out, and then we, are introducing Yes, Benedict's… There are people on the other call? Okay.

Benedikt Wagner: Yes.

Justin Florentine: So, there is a message on the agenda there that should have switched to Zoom. Sure, the one time the other call works is designed is the one time we try not to use it. That's great. Oh, here they come. Great. Benedict, I'm glad you're here. We were just talking about the paper. And I was just explaining how I'm not a cryptographer, and I, you know, more of an engineer. And so, what we were getting to was some of the trade-offs With regard to ciphertext size. Were we to adopt a threshold encryption mechanism as described in the paper? Ciphertext sizes balloon up to such a degree that even with 300 gas… 300 megagas blocks, we have a very limited capacity for them.

Benedikt Wagner: Just to be clear, what… when you say, scheme-like in the paper, I mean… Do you mean literally scheming the paper? Because I think no one ever suggested that for encrypted Mempools. Are you referring to… What was written in some chats as the naive scheme, which is the starting point of the scheme in that paper, which makes sense for a small number of parties.

Justin Florentine: Yes, for, like, 40 to 50 parties, yes.

Benedikt Wagner: Yeah, so… My understanding was that some people wanted to have a scheme maybe better than no scheme, a scheme with just a small number of parties, and if you have a small number of parties. Probably the best option is to do… some sort of naive scheme? I mean, the naive scheme is just… a linear ciphertext size, so if you, If you want to encrypt to N parties, you would have something like n public key encryption ciphertexts. Plus some small overhead,

Justin Florentine: So not, so not doing the random sampling.

Benedikt Wagner: No, exactly, yeah. You just take your… I mean, the random sampling of a comedy from that paper only makes sense if you have a very large number of parties. But if you say we want a small number of parties. then you can just take your message, secret share it, send one share in an encrypted form to each party. And then, of course, you can optimize this, right? You don't share your message, you share a small symmetric key, Send that to every party. And then you need to be careful a little bit with CCA security, but essentially.

Justin Florentine: Yeah.

Benedikt Wagner: That's… that's the scheme.

Justin Florentine: Right, so I think, I think one of the concerns that we had with that was… Adaptive… the adaptive security as opposed to, like, the static definitions of it. And one of the things we liked about the random sampling approach was that you don't need to schedule a committee. So, I mean, maybe that's not a big deal. Like, maybe scheduling a committee is… It's…

Benedikt Wagner: Okay, so why is adaptive security such a big thing that the rest of the Ethereum protocol never cares about adaptive security?

Justin Florentine: Anders, I heard you trying to weigh in on this. Would you like to?

Anders Elowsson: Yeah, well, I think that we always want to have, you know, the protocol itself will select which validators that we do the reveal, so to speak. I don't know if that's what we are discussing here. We can never let the key publisher, or, for example, the sender can never be allowed to select which validators that we do the reveal. So I just wanted to emphasize that.

Jan Bormet: like, in the naive scheme that Benedict described, you can just, like, whenever you encrypt, you can decide from the set of all the metadata, let's say, you can just pick 40 of them, 30 of them, whatever, and decide to encrypt to them. I mean, if you want it to be more efficient that not all the validators maybe need to be online to decrypt, then you would have to do some kind of mechanism that, let's say, every block, There's some type of selections which validators are selected, are selected, that kind of everybody chooses the same one, that only these need to send something. But, in general, like, this committee sampling thing is only… like, essentially, it's an optimization that for large N, the ciphertext scale… the ciphertext size doesn't scale with N anymore, but it's constant instead. It can stay constant when n is large.

So in that sense, you have this committee center, and you always have it with the naive scheme already. only this, like, kind of subcommittee of the large committee stuff that is the optimizations that happen after the starting point in this paper. Only this is… like, this is then not relevant for a small number of parties, kind of. I don't know if that made sense to you guys.

Justin Florentine: I think it makes a little bit of sense. I think… We have been using the naive scheme as shorthand, and I don't know that I have a clear definition of of what that is. It sounds to me like, from what you just described. The sender needs to know Who it's going to send it to.

Benedikt Wagner: Yeah, but that's always the case, right? You always need some representation of the decrypt… the set of decrypting parties. That can be a public key, or that can be a list of public keys. In this case, it would be a list of public keys, because if you want a single public key, then you need a DKG. if you… okay, so let me maybe recall what the naive scheme is, because I think it's actually so trivial that it's never been written down. So if you want to have threshold encryption, and you don't care about the ciphertext size. Then there's a very simple way of building it, just using public key encryption. You take your message, you secret share it, and you encrypt one share to each party.

So, if you have N parties, this is a ciphertext size of n public key encryption ciphertexts. But if n is small, this is actually a good solution. Because it uses, well, just black box public key encryption, so you can just use whatever Kyber library you want, and have, and have post-quantum security. You need to be a little bit careful with CCA security, though, but that's… I think you can add that. I think no one ever did that, because just from a theory perspective, the scheme is so boring. But, yeah, you can use it if you are okay with just having a small number of parties. Which I'm not sure if we are.

Justin Florentine: So, one thing worth talking about with CCA is… how important is it, right? Like, CC…

Benedikt Wagner: It's really important. It's… like, for Encrypted Mempools, it's very important, because essentially what we give to the user is, is a decryption service, right? So the user can submit cybertext, and the committee will decrypt them. So this is exactly what you have in a CCA security game, you have a decryption oracle.

Justin Florentine: Okay, so you would describe the naive… Design as a decryption article, right?

Benedikt Wagner: No, no, the set of parties who decrypt every slot, for example, this is a decryption oracle. So, if you are malicious, you can just send cyphertexts, and then they will decrypt it. So, that's why it's… pretty obvious that you need CCA security, because in weaker notions, you just don't… Give the adversary the power to send ciphertexts and get them decrypted. So I think CCA security is not… to me, this is not debatable. Like, any scheme that we use for encrypted mempools should provide some form of CCA security.

Justin Florentine: And you think that's CCA2, right?

Benedikt Wagner: Yes. And the scheme in the paper only has CCA1.

Justin Florentine: Right.

Benedikt Wagner: But the naive scheme. can be made CCA2 secure, I'm pretty, pretty sure.

Justin Florentine: Okay. Great. So that's an action item here. How would we get the naive scheme to CCA2? I'm sorry, I interrupted you. Would you mind continuing your description of the naive scheme, or were you done?

Benedikt Wagner: I mean, depends on where you stop with naive. Like, this… what I described was very, very naive. Of course, now you can start optimizing it, right? You can just, instead of encrypting a share of your message, which may be large. To each party, you encrypt… you take a symmetric key, you encrypt your message under a symmetric key, and then you share that symmetric key. and Encrypt the shares of the symmetry key. So that's essentially hybrid encryption, And then if you want to have CCA security, I guess what you would do is you would add some sort of one-time signature to it. And… I guess you would hash the symmetric key with the one-time public key together.

before you use it to encrypt the message or something. So there's for sure a way to do it. So, yeah.

Justin Florentine: Okay. I thought that somebody had written something recently with regard to a hybrid scheme kind of like this.

Jan Bormet: And of all the schemes are hybrid schemes. Because you're not, like, all the literature on the threshold encryption stuff. Basically, all of it is hybrid encryption, in a sense that they only care about encrypting, like, at least in the… in the groups world, they only usually encrypt group elements, and then you just assume, okay, I'm going to encrypt the random group element and hash it to derive some… Symmetrically afterwards, like…

Justin Florentine: Hmm.

Jan Bormet: Like, it's kind of… I mean, there's some, especially Benedict, you know, right, there's some… some things that you need to be careful with respect also to CCA2 security, but, You can treat it essentially like these key encapsulation mechanisms. Where you, like, just… Encrypt a random key, and this is the KEM part, and this is usually what you target with the, threshold, silent, batched, whatever scheme. And then this hybrid transform, you will just put it on the end of it.

Justin Florentine: Crap.

Anders Elowsson: Can we discuss, multi-message public key encryption? We had a little discussion about that also. Is that something to add? To this, or…

Justin Florentine: Yeah?

Benedikt Wagner: I mean, sure, you can edit, I'm not sure if it makes things so much better, to be honest. And it's also, you need to be very careful about the security notions that you get, because… again, this is a question of CCA versus not, and then if you just take a random paper that Implements this, and most likely it's not the appropriate security notion. But yeah, in general, this is, of course, something you can do. You encrypt multiple messages to multiple receivers. Of course, you can try to share, like, a large part of these cybertexts, to amortize it, to use it for all of them. Instead of having one completely independent ciphertext for everyone.

Anders Elowsson: Another thing that maybe… I think that we didn't… we dropped in the conversation here was that the idea with this has been that we can do both PQ and non-PQ at the same time. So that's something we can mention there. I'm still not sure if this is a good solution, but it's just something that we could start with, having people use the non-PQ version of this naive scheme, and then they can have the PQ version available for them, and just switch over when they want to.

Benedikt Wagner: But in… okay, in this case, why would anyone use the non-PQ? Solution?

Anders Elowsson: It's… it's the… with the reasons that we discussed previously. They will have to pay for the data. So, if you do the PQ solution, I assume that we would have to implement it in such a way that we put these in blobs. And try to… because otherwise it just gets too expensive, probably. And so…

Justin Florentine: But it doesn't grow… it doesn't grow with regard to any of the sharing size, right? It's… it's… it's overhead that's introduced linearly, but larger, because of the PQ… the difference between the PQ and the classical crypto, right?

Anders Elowsson: It's linear, yeah.

Justin Florentine: Okay. Yep.

Jan Bormet: But is it a point that you guys want to reuse the, like, the validator keys? For this encryption thing?

Anders Elowsson: Yeah.

Jan Bormet: I could have done it yet.

Benedikt Wagner: There's no way to do it PQ. Okay.

Jan Bormet: Yeah, because then the point, that's the advantage of the non-PQ, that you can do it now, right? Assuming that your validators are fine with reusing the keys for this, right? So, whenever you reuse…

Benedikt Wagner: But even then, like, the scheme… the numbers that you got from, maybe from the paper are then no longer accurate, right? Because the… what was assumed in the paper is some sort of just LDamal over pairing-free group, but we have now pairings, and then LDamal is not secure, so you just… We'll have some… Some overhead that is small, but… But I mean, for the future, if you want to reuse validator keys, I think it's gonna be pretty hard, because the validator keys in the future… will most likely not be letters-based keys, right? So, Let's say the validator keys in the future are keys of a hash-based signature scheme, so then there's no way that you can use them for threshold encryption.

Justin Florentine: I, yeah, I think that's a thing that we kind of had to plan for anyway, you know, some type of additional purpose, specific purpose keys being issued to validators, or validators generating them and registering them somewhere. But I think they have that problem anyway with any type of PQ transition, so… Okay. Brainstorming. Anybody else have anything that they want to throw out?

Jannik Luhn: I have one question, maybe, for the scheme. The non-PQ version, how does it compare to other non-PQ protocols? Is it worse? like, assuming people don't need, or don't care about PQ for a while, would it be better to enshrine at, like, the optimal non-PQ thread encryption protocol, if there's something like that at the moment?

Jan Bormet: there's, like, no optimal protocol if you, like, there's always some issue, right? So… If you want to do a… if you're fine with doing a DKG, or, like, a ZRA ceremony, and have people publish something, then, Yeah, you can… you can do that, but this is, like… Assuming you want to do non-Q, then the question is, do you want to do a DKG? Do you want to do a CRS, do you want better data to publish some additional information? And if that's the case, then, yeah, you can… that's then more the trade-off, right? It's not… Yeah, the ciphertext size will be more efficient if you do batching than the… kind of the decryption will be more efficient, or the decryption communication, but then you always have to do either DKG or some CRS for silent setup, and maybe have validators publish additional keys. I think the cool thing about your naive scheme and doing it now, kind of the big advantage is that

You can more or less reuse all the existing key infrastructure, and you just… I kind of use them in a slightly different way. That's the best, like, you don't need to do any setups, any ceremonies, any, Anything like that.

Jannik Luhn: I see. Yeah, makes sense. I mean, personally, I think DKG… would be acceptable, maybe? I guess it depends. It would probably mean that the, committees would have to be, like, used for longer periods of time, because otherwise it's too much overhead.

Jan Bormet: So, I was thinking about this more, let's say, let's say we… we were fine with doing non-PQ, and if you want to do, like, what about, for example, let's do threshold model, or one of the silent schemes, or even one of the silent batching schemes, and kind of my… my view is that… probably it would be better, like, probably would be better not to do a DKG. Let's say, if you do a DKG, you're always kind of… fixing the num… fixing the parties for all of the future, right? Let's say I do DKG with 100 parties, then these will have to be the parties, and when somebody goes offline, suddenly you only have 99 parties, right?

nobody can join, essentially, without rerunning a DKG. So, kind of, my view on that, that probably the best way to explore there, in this kind of with these constraints is that you do a CRS with a small ceremony, like, you use the 100 parties that you would have done the DKG with to set up a CRS, and then you have… you kind of… enable that from this point, with the caveat that now you have this kind of strong assumption that these 100 parties really generated the CRS faithfully. Then you have, then you can use, kind of, the silent properties. And still avoid doing another large terminal, right? Because then afterwards, like, you have the CRS, now you assume it's trusted, and then…

Anybody can just, let's say, publish some public information for their keys and be a committee member at that point. And people can also leave, you can change the committee every few epochs if you want.

Jannik Luhn: I'm not sure if I understood this correctly. this setup ceremony, CRS, I don't know what that stands for, but would it basically mean that only a subset has to do that, and as long as we're trusted, then everything is fine, but then the whole validator set could participate, or would it then only be these 100, Entities we can participate.

Jan Bormet: it works like many, like, basically all of the schemes with a silent setup, and I think also all of the batching schemes, even if they don't have silent setup. Oh, no, sorry, not all of them. Yeah, I think all of them. They need a, like, CRS, and the CRS is essentially, like, a trusted, structured reference string. And this usually…

Benedikt Wagner: hours of Tao thing that we had for KCG commitments. A similar thing.

Jan Bormet: Yes. And basically, you can… there's ceremonies for generating these. Like, for the KCG from Ethereum, there was some huge ceremony where many people participated, and organizing it is quite difficult. It's a pain, at least that's what Benedict told me. So… Like, maybe organizing it with just 100 participants is, like, a trade-off that you can do for now. It means that you have kind of a trust assumption that says. You need to be sure that at least one of the 100 parties is… Honest, and destroyed their secret information after the ceremony. And then you can run such a ceremony. And from that point then, okay, if you now… if you're, like, keeping in mind this trust assumption, any party can basically join. The only thing is that usually, as, like, the individual public keys, if you want to do the silent scheme, silent stuff.

as the individual public keys, you kind of need to publish some information with, like, some function of your secret key in the CRS, like, some individual public key again, so you cannot just use the validator public keys now, like, you need to… the validator needs to still publish something, but that's non-interactive at this point. Like, I… like, I as a validator… like, the 100 people do the CRS once, then there's some public information on that, people start trusting it, and then I, as a validator, I see the public information, I publish some group elements, and then I can be a committee member. Essentially.

Jannik Luhn: Okay, cool. That doesn't sound too bad to me, to be honest, so… Wouldn't agree with that out as well.

Jan Bormet: And the, the issue…

Justin Florentine: I find that interesting, yeah. I think scheduling it, coordinating it, is a challenge, but it also doesn't have to impact any of the current consensus layer duties.

Jan Bormet: Yeah, essentially, like. you can also have a trusted part, you can tell me to generate one, I will generate one for you, but then you need to trust me, right? Like, there's some, you can, like, if you want to play with something, then this is also some option that you have here, like, play with how do I generate the CRS, because aside from, like, additional cryptographic assumption, pre-quantum stuff, and some idealized models, this, these silent schemes are otherwise, otherwise quite performant. Like, some issue that you have with them, that these individual public key, if you now want everybody's data to be a potential committee member, then everybody, let's say, per, per blog, the committee is size 100 or something.

Then everybody would… kind of have to publish order of 100 group elements, so having, like, hundreds of thousands validators publish that is… by far… way too large, right? So that's a problem. And also, whenever you want to, the later… let's say the system works, and after a year you start to realize, oh no, this… maybe we need to fix this trust assumption, this CSS that we had generated by, like, some small committee only, then you need to run a new and larger ceremony, and then also everybody has to publish new individual public information, right? And you can… to reset the system. But I think if you want to get something running fast, this is still much better than doing a DKG, because it's somewhat scalable, except that you have to keep in mind this trust assumption.

Gottfried Herold: just one thing to add here is that, I mean, we have this experience with our parts of Tao ceremony, and it just needs to be… I mean… I mean, there's, of course, the trust assumption, the coordination issue to actually get these, say, 100 people sort of work on this CRS generation setup. One thing to keep in mind here is that, sort of the… it's not just, sort of, the coordination issue, but actually, sort of. writing the software to run this distributed protocol. This is actually quite non-trivial, and it depends very strongly on what actually the shape of the CRS is. The powers of Tao is actually a particularly nice case, in the sense that the amount of interaction needed between the parties during the ceremony is very, very benign, and not necessarily every CRS is as nice as the powers of Tao one.

So there is maybe vast differences in how hard it is to actually implement this.

Jan Bormet: So, from my experience, there's kind of three types of CRS. There's the powers of tau stuff, depending, like, then there's… it's, like, a small difference in which type… is it only in the… in which of the source group it is when you have pairings?

Gottfried Herold: Yeah.

Jan Bormet: Then there's the pose of Tao Withholds. I'm assuming this also would be easy, right?

Gottfried Herold: Not so sure, but I didn't think about it.

Jan Bormet: Because you can… I thought that you can just not publish one element, probably, and then it should be fine.

Gottfried Herold: Yeah, the point is in the powers of tau ceremony, is that, basically, if you have some powers of tau ceremony for one particular value of tau, then I have another tau prime, then I can basically produce, basically the result for G to the… for tau plus tau prime, and sort of… if I want to sort of get G to the tau plus power prime in brackets to the alpha, whatever, for every value of alpha, I can basically use the other values to sort of do the updating. So there's actually extremely little interaction possible, and as soon as I have holes, this nice strategy doesn't work any longer. So I'm not sure whether, sort of, the niceness carries over.

Jan Bormet: Yes, okay, and then there's the cross-terms versions, like the…

Gottfried Herold: this game.

Jan Bormet: that have cross terms, and they're… I mean, I didn't check, like,

Gottfried Herold: Yes.

Jan Bormet: one would have to check which CRS is easiest to generate with.

Gottfried Herold: Yeah, yeah.

Jan Bormet: Maybe, which can reuse the most part of the software, if one wanted to do that.

Gottfried Herold: Yeah, just… which is interesting, I mean, in general, of course, with general NPC, you can do it always, but, I mean, powers of Tao is really, really nice, in that there's very little interaction needed. And I'm not sure to what extent that carries over. This… we would need to have to check.

Benedikt Wagner: I mean, I fully agree that… This is much better than a DKG.

Gottfried Herold: Yeah.

Benedikt Wagner: And… But I… for me, this is like a… it sounds completely unrealistic to do that, which is a lot of, as Gothi says, is a lot of work, like, doing it properly, just because it's an interactive protocol. to do that for a non-PQ solution. I'm not sure. I think this sounds like a lot of effort for something that you will completely change Pretty soon. And if you use something with less effort, then I think it's much more likely that People will actually do it.

Jan Bormet: Hmm.

Benedikt Wagner: Yeah.

Jan Bormet: like, something nice to keep in mind about the ceremonies is how I understand it, that you can continue computing on them, right? You can just add… like, you can start with something scrappy and small now. with 10 people, right? And get it going, let's say, as a prototype. I still agree with you, Benedict, overall, by the way, that probably the best way to really get it quickly would be the naive thing. But if you want to do the CRS thing, then I think you can start with 10 people, and then the system grows, and now you think we need to revisit this trust assumption, so then you can use 100 people and kind of continue calculating where the 10 people left off, right? So you can always.

Gottfried Herold: Is that possible? Is that possible for all TRS ceremonies? I mean, for the powers of Tao, yes, but I'm not sure… this is exactly the property that I've mentioned before. I'm not sure whether for the other version, this is also possible.

Jan Bormet: Yeah, yeah, I was… I was… I only know about the, like, kind of the rough idea of what the Ethereum ceremony, I don't… I'm not sure.

Gottfried Herold: Yeah, yeah, yeah. I mean, this… I think, I mean, this is pretty much related to this kind of complexity issue that… where you basically use Let's see, I fear this may be only possible for parts of Tao, specifically.

Jan Bormet: Yep. Where the schemes… yeah, okay. Well, this kind of limits which type of schemes you can… could then instantiate such a thing, right?

Gottfried Herold: Hmm.

Jan Bormet: Some, schemes, they need powers of tau in different gen… with different… with respect to the same tau, but different generators for, like, optimal stuff. I think that should be fine, though, right?

Gottfried Herold: I mean, the ideal way would, of course, if you could just reuse our powers of tau that you already have.

Jan Bormet: That kills batching, I think. I think you can do that, but that kills batching.

Gottfried Herold: Yeah.

Jan Bormet: And it limits the committee size probably to 64. I don't know, and to what extent the silence schemes need the G2. Rose of time.

Gottfried Herold: I mean, it's… I mean, if you do… I mean, there's this thing in the pipeline that I haven't will probably write to you on today anyway. I mean, we can probably do without batching. There's this kind of idea, we just use threshold IBE.

Jan Bormet: Yeah. I think then the only silencheim that uses this type of CRS, and has competitive ciphertext size is still from Gag at I.

Gottfried Herold: Hmm.

Jan Bormet: But they said, I mean, it has, for example, only GGM proofs, right? Look.

Benedikt Wagner: Yeah, threshold IPE, right, for Cotti's approach, really.

Gottfried Herold: Maybe special diaby.

Jan Bormet: It says threshold ID, so I don't threshold ID, right?

Gottfried Herold: A silent threshold IB was exactly… I mean, a silent threshold IB, but exactly what the scheme that I'm bringing up…

Benedikt Wagner: You mean SunJam's… SunJam's first scheme with silent strategy encryption? That was not IBE, no?

Jan Bormet: Yeah, you can do IBE if you choose the gamma to be a hash of some ID.

Benedikt Wagner: I see.

Jan Bormet: I mean, okay, what is Gamma? Gamma? Is this essentially the… thing that you do the BLS signature on, right?

Benedikt Wagner: Yeah, I think I see it.

Gottfried Herold: Yeah.

Jan Bormet: then it's an IBE. I mean, it's not proven as IBE, but I think, since it's… essentially, it works like Bunny Franklin's IBE with some additional verification equations, like, for this witness thing, but… I think it should… be… I'd be straightforward.

Justin Florentine: Okay, let's… I'll slow down here for a second. We're moving kind of fast, and we're throwing around a lot of ideas here. But the CRS sounds like a very promising area that we should, we should pursue. If we do, we need to reconsider… maybe going straight to PQ, right? it might be too much work to actually try to entertain doing it both pre- and post-quantum.

Benedikt Wagner: post-quantum CRS, I don't know if there's a solution.

Gottfried Herold: Yeah, because the protocols we have, I mean, if you want to make a post-quantum CRS ceremony, you basically, I mean, you basically end up doing a fully-fledged MPC protocol.

Benedikt Wagner: It's also not even clear what the CRS would be and which threshold Encrypt… post-quantum threshold Encryption protocol would use such a CRS.

Gottfried Herold: Yeah, yeah.

Jan Bormet: I think with PQ, there's basically nothing better than a naive scheme right now. Right.

Benedikt Wagner: Yeah, pretty much.

Jan Bormet: Bill?

Gottfried Herold: Yeah, a little bit of things, but not much, you know?

Justin Florentine: So, is it safe to say that with the naive scheme and post-quantum, it's really a committee scheduling problem? Like, it's really figuring out who you need to target, how do you break up your shares, how you deliver them, and then they need to decide when to reveal, and the protocol needs to decide how to punish them if they, you know, collude or fail to reveal.

Gottfried Herold: I mean, there's also the problem that the data sizes grow quite a lot. And, I mean, it's just the scaling of the data complexities.

Justin Florentine: I mean, they do, but they're linear, we said, right?

Jan Bormet: I mean, linear in the number of parties, right?

Gottfried Herold: number of parties, and you have to… and there's… I mean, if you do it naively, unless you do some threshold IBE scheme, there's also sort of… you have to do that for every… for every encrypted transaction. And the base size of the individual ciphertex also grows quite a lot. I mean, this linear growth is… that's kind of the problem. Just the concrete numbers are probably gonna be bad.

Justin Florentine: So it's gonna punish bandwidth pretty hard.

Gottfried Herold: Yeah. That, yeah, it's mostly a vendor's problem.

Anders Elowsson: Yeah, it would be… we would have to charge the transaction… the senders quite a lot. You cannot do many per block.

Gottfried Herold: Yeah, it's not just the centers, it's also the problem that the committee, if you sort of select a committee randomly from the validators, and those validators who are selected actually have a much… have a huge bandwidth requirement spike, because they have to basically send out decryptions for every single encrypted trans… every single encrypted Mempool transaction.

Benedikt Wagner: But that's not.

Gottfried Herold: On this one.

Benedikt Wagner: I mean, that's not the main drawback of a naive scheme. This is… this is a drawback that you have with every scheme that is not doing batching.

Gottfried Herold: Yeah, or threshold, yeah, or threshold IP, yeah.

Justin Florentine: Can we better define what we mean by batching? When I hear batching, I think, okay, everybody that's participating, in maybe this, or wants to participate in this block. batches their transactions together, and they're all, you know, encrypted with the same key. Is that an oversimplification?

Gottfried Herold: Yeah, it's a bit of a simplification. I mean, this is one way to achieve it. In general, but batching, I mean, more generally, the point is what you want to achieve, is that sort of the… The bandwidth complexity does not, for the decryption part, actually does not grow linearly with the number of, encrypted transactions.

Jan Bormet: Yeah, it's kind of the opposite, what you said, like, the encryption should be the same. Like, you should not really know… I mean, yeah, you notice because you run a different protocol, but you should not have to coordinate with other encryptors, let's say. But, the… instead of sending, let's say you have B transactions in the ciphertext, and in the normal threshold encryption scheme, if I'm a validator that is scheduled to decrypt, then I need to send, let's say, 100 individual decrypts, like, every single ciphertext, I need to have to send an individual partial decryption. And if it's a batching schema, I can just compress this to one. So it's kind of about the succinctness of the partial decryption when trying to decrypt many transactions at once.

Justin Florentine: Oh, so it's batching the shares, not so much the participants, okay.

Jan Bormet: Yep.

Justin Florentine: Okay. Wow, I said we were gonna brainstorm, and you guys gave me quite the storm. We have a lot to think about. We're coming up on, about 3 quarters of the way through the meeting, and we do have another agenda item that Jannik wanted to cover, so I want to reserve a little bit of time for that. Do you want to get into it, Jannik?

Jannik Luhn: Sure. So basically… it's motivated by, the fact that I'm not really convinced that enshrining a specific server encryption scheme is, So the best solution? First of all, because, as we've just discussed, there's still lots of cryptographic development to be had, hopefully, so if we try and find something now, we probably won't end up with the best scheme. And… but even if we had the best scheme, then, we will probably only be able to have a small committee, sampled from the value dataset, and I'm not sure how much I would… how trustworthy that actually is, especially because there is misbehavior in… that is not punishable, because it's unobservable. Basically, if they decrypt messages early, and then,

yeah, peek and see what happens, and then, depending on that, send additional transactions or something like that. That's, nothing that would be visible from the outside. And, it's also bribable in a way that's potentially, Trustless, so you could maybe set up some sort of, bribery smart contract. So, yeah, in general, not too excited about this. And Lucid doesn't really have these issues at the moment, because the key publishers can choose their own scheme, and they can switch very quickly. And also, the key publishers are known entities, and they have reputation. Which kind of factors in into these attacks. I'd rather trust a small committee that I know, that I know the names of of the people, or the users can basically decide on that.

So I was thinking maybe a compromise that we could do between Lucid, that has this optionality problem that we're trying to solve by enshrining, and enshrining one scheme, would be to, have kind of a whitelist of, of… key publishers. Basically, do Lucid as it is, but whitelist the set of key publishers, so that… and only key publishers who are trusted to release their keys would, yeah, would get under that whitelist. And now the main question is, of course, is how to come up with the whitelist, and one solution might be to let the validators vote on that list. Which is… I think, should work. It's maybe a bit unusual in Ethereum, but there is already a little bit of voting by validators, one on the block S limit.

which maybe is just one parameter, so it's maybe much easier to decide on it. But also, arguably, they vote on the set of block builders of the protocol, but that's maybe a different decision. But yeah, just wanted to put that out there and, yeah, see if you guys have thoughts about it.

Jan Bormet: So it's basically Lucid plus, there's, like, kind of a restriction which services can be used, right?

Jannik Luhn: Exactly.

Gottfried Herold: I mean, and you would use this Lucid with an actual threshold scheme, or just a sort of a prescribed set of decryptors, and, I mean, some of them may be threshold, or maybe multiple ones, and some of them are thresholdized, some of them are different, or what.

Jannik Luhn: Yeah, it wouldn't be prescribed by the protocol, but the validators would only accept entities that they think will release their keys, which basically means some sort of threshold committee, I would assume.

Justin Florentine: Is this a new role that we would be enshrining? It sounds to me like we could take an approach… out of the ePBS book, right? Where we introduced builders as a new staked entity, that… You know, had responsibilities and could be punished. Would that… be necessary.

Jannik Luhn: I'm not sure. I guess in Lucid there is already a little bit of punishment. I'm not sure how easy it is to add additional ones. I guess you could think of letting the Valley dataset, like, socially slash the key publisher initials, but that probably opens up a different kind of rooms. It's even more difficult.

Gottfried Herold: I mean, my main concern about this is more like, sort of that… a certain set of, sort of entities who provide such a service, which might be some threshold committees, maybe it's even somebody who just says, hey, I will publish, sort of, your keys, trust me, and I'm just a single entity, I just won't steal your data. Trust me, basically something like a trusted broker. which, I mean, from the protocol's point of view, it's okay. If you use it as a user, that's your problem. It's just a question whether you want to protect the user, or whether you want to protect the protocol. You have to make a bit of a distinction, because this kind of…

And trust mechanism is actually supposed to protect a protocol, and not the user who's actually sending the encrypted transaction. So, different… so you could actually have some… Multiple entities with different trust relationships to the actual user who uses their service. My main concern here would be that, I mean, if you sort of have this, and I mean, it's actually, actually, they get fees from their users who use their service, it will probably lead to certain entities, starting up such a service, then maybe they sort of… get voted in by the protocol, by the other validators, but at some point, you might have some kind of ossification process going on here, and it will be very difficult for new entities, for newcomers, to sort of make a better scheme, maybe a better threshold encryption scheme or whatnot, to actually,

get in into their scheme, because basically the protocol or the validators vote for a sort of a curated list, and now if you're sort of are a newcomer, I mean, you have to basically socially reach out to this whole set of validators, hey, please add me to the list, and I am good, and I'm a good guy, but, I mean, you cannot really show that you're a good guy, because nobody can use your services until actually the other people have voted on it. So, you've actually run into a bit of a chicken and egg problem here.

Anders Elowsson: So, one thing we can say about this is that we can always allow, These non-whitelisted entities to go after the whitelisted entities. In this case. But I still think that the idea as such might be interested. Well, being interesting is sort of… you have to be wary about it being sort of a stratum for cartridization within.

Gottfried Herold: the…

Anders Elowsson: the valid data set, so that with this mechanism, we would sort of over time, perhaps, you know, compromise… like, the big overhanging risk is that we compromise Ethereum as a whole, because we bring this pressure for… for validators to sync with each other and cartilize with each other. And, and, and, and… This becomes sort of a, like, a brewing ground for them to start and collaborate with each other and decide between each other who they're going to vote for. So that's something that… if we… if I compare it to the previous version of this Jannik that you had in the ERP, Where the transactors instead indicate which entities they trust. In this way, in such a mechanism, we are sort of safeguarding the protocol from this whole game theory in a way that felt

More safe from that one perspective.

Gottfried Herold: Yeah, and I'm not sure to what extent the validators actually have to coordinate, because, I mean… I mean, the validators would not have to vote on the list of allowed entities, but you could have a separate vote for each potential entity candidate. So, there seems not much, because it's basically a… it's basically an individual vote for each Candidate, so there's not much coordination, actually, that is needed. I don't need to.

Anders Elowsson: Or they have to… I mean… If you are just at the thresholds.

Gottfried Herold: I mean, I would envision this, basically, to be that, basically, validators can sort of send out a message, hey, I want this validator to be added to the trusted list. They can send out a message. It doesn't even have to go on-chain, and basically, once such a service wants to basically be included into this list, they basically have to provide a special message where they basically produce sufficiently many signed messages from sufficiently many aggregators to be included into this list. And in particular, there is no… not much, well, coordination issue. Basically, the one who needs to coordinate is that the… the new entity has to basically reach out to each validator. But not, that the validators don't actually have to talk with each other. At least on the… I mean, at least from a… as far as the mechanism is concerned.

Anders Elowsson: Yeah, but I mean, it's just the…

Gottfried Herold: I, I, I agree that.

Anders Elowsson: Yeah, I…

Gottfried Herold: Dangerous, totally agree.

Anders Elowsson: that. I think that, that's still, I don't know, you give the validators this… This option to… Bring profit to various entities outside of the mechanism, and then Do you need a minority of the validators to vote in a certain direction? I don't know. I used to…

Gottfried Herold: I mean.

Anders Elowsson: bit… like, I like the idea, it's innerative, but I've still felt a little bit wary.

Gottfried Herold: Yeah, I'm just saying that, sort of, compared to other, sort of, similar proposals where also financial incentives, like, I don't know, trying to, sort of, direct, rewards to, to research, I mean, it's a bit different, because, sort of, the… the options to vote for are not… are not pooled. That makes it easier from a mechanism design point of view.

Jan Bormet: Can you repeat me?

Gottfried Herold: Agree.

Jan Bormet: Can you remind me why this optionality actually is such a big deal? Can I not just… let's say there's, like, say, some exchange or something, there's some trading going on, can I not just… let's say I want to do front-running or something. So, Anil, because I want to…

Gottfried Herold: The problem…

Jan Bormet: I mean.

Gottfried Herold: The problem with the optionality is that I can sort of exercise my optionality or not after I know other encrypted transaction.

Jan Bormet: Yeah, after you know transaction after you, right? I think the one before is not so bad, because anybody can observe the state and, like, revert the transaction, right? But the after ones that are bad, that I didn't think about.

Gottfried Herold: Yeah, exactly. That's the reason why, sort of, this other idea by Jannik, that they basically make some ordering that basically your encrypted transactions come with ordering constraints, would also work, but sort of has very bad UX.

Jan Bormet: Is there some, like… is there some, let's say, data of how many transactions per block or per e-book would be currently affected, or, like. With current Layer 1 activity?

Gottfried Herold: very hard to say, because, I mean, to be fair, if we had such a feature, maybe we would see more usage, so there's not… it's absolutely unclear how big the induced demand is.

Jan Bormet: And what is the current demand? Like, what is the current, without the feature? Essentially, does it mean that trading on… I mean, you could argue, okay, trading on Layer 1 is not happening because there can be an MEV, right? But it's not much, because I don't know the actual number, right? It's not too much. Layer 1 MEV right now, or is there?

Justin Florentine: It's… it's hard to detect. I think our number's around 65 million a year.

Jan Bormet: Okay.

Justin Florentine: Well, I would say in losses, if you look at it from the other.

Gottfried Herold: And, of course, I mean, as I said, I mean, the big trades… the big, sort of, vulnerable trades are probably not even settled by a L1 because of that reason, so…

Justin Florentine: Exactly.

Loring: Yeah, I think the demand is probably most represented, by the volume passing through private Mempools rather than through the public Mempool.

Jan Bormet: Because then, if we, like, introduce a Mempool now, and then the scaling, like, we just move the bottleneck from MEV to scaling, then, I mean, you pay the cost some way or another, right? The only way, like, you need to look at the extraction site then. Like, maybe you say if this… if you have an MEP protocol, the extraction is kind of more fair? And not so centralized. Like, because the fees have to be larger, right, and so on, then…

Justin Florentine: Okay, we are, go ahead.

Anders Elowsson: Yeah, I think one thing that could be interesting for Jannik, if you wanted to look into it, is perhaps… Like, some sort of assumption about if we do this Trust… trust assumption, but on the… At the transaction level instead. might it look like? We haven't… we… we are worried about various things, and we are worried about how it can be implemented, etc, and what… what How it will lead to some entities monopolysing, but maybe it can be analyzed a little bit deeper, and like, how will the builder… builder will construct a set based on the options it has available to it? I don't know. Maybe there's something there to… to think about.

Jannik Luhn: Yeah, I will definitely think about it a little bit more. But yeah, I see kind of the main argument against it, that it's… Yep. But we'll… we'll consider it again.

Justin Florentine: Okay. Great. Very, very busy, lively call, everyone. Thank you. I think the main two things that we want to take away from this, I did record this, by the way. I will post an AI summary on the meeting agenda once it's made available. I think as far as next steps, we kind of have two directions that we want to go into. I think we want to look into the naive scheme, threshold Encryption, naive scheme, consider how we can get that to CCA2, and if that remains a research direction we want to continue in. And then the opposite, you know, stick with Lucid as is, and consider validator whitelisted key publishers. We need to consider the game theory around that, so the markets and tokenomics around that.

And figure out whether or not that could be acceptable, and try to quantify the cartelization and centralization risks that come with that. Questions, comments, concerns, refutations? Criticisms.

Anders Elowsson: Yeah, and maybe we can mention that we are also, sort of. Yeah. Like, there's a… there's a risk. We have these two options, but there's also a risk that none of these options will be good enough. At least for enshrine. Good to mention that.

Justin Florentine: Sure. Yeah, I think that's worth reiterating, like, the optionality problem is a real one, and if we can't get around it… let me rephrase that. Lucid, as it stands right now, acknowledges the optionality problem and charges people a financial penalty for it. I think we can conclusively say that that's not good enough, and we need some stronger protections from optionality. Fair?

Anders Elowsson: Maybe.

Justin Florentine: Maybe. Okay.

Anders Elowsson: Probably.

Justin Florentine: Good enough. Take maybe. Great. Alright, thanks everybody, appreciate your time, great turnout. Thanks again.

Benedikt Wagner: Thank you. Bye.

Jan Bormet: Thanks, Billy.

Jannik Luhn: Thank you, bye-bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.