Encrypt the Mempool Call #9

Transcript

Loring: Hey, everyone.

Jannik Luhn: Nope.

Gottfried Herold: Hello.

Loring: Is EF ZoomBot an actual bot, or is it… A person with a… acute handle.

EF Zoom Bot: Hey, this is, Mark, or Woolobim. You're now the host. Just wanted to make sure you could kick it off smoothly.

Loring: Oh, wonderful, thank you.

EF Zoom Bot: Alright, have a good meeting, y'all.

Loring: I know, Justin and Anders are both on holiday. This week, so the meeting may be a little bit smaller than normal, but we thought It was important to keep the conversation going. So we'll wait, just a couple minutes for some folks to join, and then we'll start… At latest, at 5 past the hour. And I'll be recording So others can catch up, even if they're not on the call.

What role? Bye. Thanks for your time. What time? What about Are you real fun.

I guess we are already recording. I guess our… friendly EF Bot, started that, so… Let's go ahead. My name is Loring, and this is Encrypt the Mempool number 9. As mentioned earlier, some of the regular contributors are not with us this week, so it's a little bit smaller group, but we wanted to keep the conversation going in their absence. We had a wonderful discussion, last week, particularly about Enshrinement and about the Validator whitelist approach, and so we wanted to continue on both of those topics. As you can see, we have 3 points on the agenda. The first two are open questions from last week's call. The first, enshrinement. Are we okay with a non-PQ temporary solution?

Number two, regarding the validator whitelist approach, how do we prove, number one, withholding? And number two, key selling, and can these proofs be automated? And then there was a third point added. About achieving censorship resistance for the original EIP-8105 trusted set, and… Anders briefly mentions at the end that that also has some implications for the Validator whitelist approach. Does anyone else have something they'd like to add to the agenda? Okay, then we will dive in. Starting off with enshrinement, are we okay with a non-PQ temporary solution?

There was a robust conversation last week among some of the cryptographers, Does anyone have, either a summary of that conversation they could provide, or, some comments regarding the question itself?

Gottfried Herold: Well, I mean, I'm not… I don't 100% recall all of the argument that we basically made last time, so this is a bit more on a more personal take. I mean, even to the question itself, I mean… I think it roughly… it very, very strongly depends on what kind of temporary solution you have. I mean, you can have a solution where all of the non-PQ stuff happens essentially off-chain. And, sort of, the protocol itself is not strongly aware of, sort of, one of it, or one where it's very, very strongly enshrined. So, in a way, it depends. I mean, you could have a solution where you say, hey, you have this kind of scheme. And then you basically flip one switch, and then you change to maybe some kind of future PQ-safe scheme, and then everything will work out fine, and the required change is minimal.

This is very strongly in contrast if you sort of have to build the whole system up from scratch. a new, with a potentially completely different design for a PQ-safe scheme. And so, I think this kind of question cannot really be decoupled from the question, what design you want at all. That's… that's the unfortunate, well, take on this. Because some schemes are very, very much, much more easy to upgrade to a PQ-safe solution than others. So, I mean, for a more… on a more… Well, well, a bit of a more… put it on the more action-level side. I mean, the question is more, okay, what kind of design do we even want, and sort of how bad is sort of optionality? Do we want to avoid it? Do we even want to use threshold encryption or not?

Like, I mean, if you sort of go for some Lucid-style design, which essentially does not strongly have all of this kind of threshold encryption in protocol, or if you do something else which does it, then it sort of very, very strongly depends, and I mean, at the end of the day, what we would need is a security analysis that basically states very precisely what sort of the requirements on the actual encryption scheme, or not encryption scheme, but on the cryptographic Parts of it has. Then you can evaluate, okay, what are the post-quantum alternatives? And how likely do we believe such an alternative to exist at some point in the future? I mean, if it's just that, okay, we have some alternatives in principle, but they are maybe not efficient enough, then it's a very different picture than if we had no idea at all how to build such a thing in a post-quantum secure way.

That's… that's basically kind of what it boils down to, I think. So, I think this is sort of a question that should be asked after the design, not sort of in advance. No, that's just my take.

Loring: Yeah, as… Jannik, go ahead, I saw you took yourself on… off mute.

Jannik Luhn: No, I just wanted to, like, from what I remember from last week, we did discuss that it might make sense to ask the broader Ethereum community first as well, because if… they could say that having anything that's not PQ in the protocol is, like, not an option at all, then that already constrains us a lot, so that might already be valuable information to get even before we start designing anything.

Gottfried Herold: Yeah, I mean, the thing is that designing anything sort of… I mean, usually when you design anything, you sort of design, hey, we have this kind of magic black box cryptography, and then you ask later what the, like, how to actually instantiate the black box, so it's kind of… sort of the position. The PQ safety comes light in the design process anyway, but I agree with Jannik. Always.

Loring: as a non-cryptographer and as a non-protocol developer, it was a really interesting conversation, and, I would say my summary was There were kind of 3 questions which are… would help us answer this question. And Gottfried, I think you mentioned the last on my list, but the other two are, how much time and effort would it take Ethereum core developers to implement the non-PQ temporary solution. The second question is, how long will that non-PQ temporary solution remain effective? And there was a lot of interesting conversation there about how soon can we expect PQ, whether, the public Mempool would be a juicy, target for someone with that computing power. And if it was attacked,

would an attack be detectable, and what would be the fallback, in case of attack? And I think those are all interesting questions which, we probably just scratched the surface on and did not reach any conclusions on. And then, the third question, which Gottfried mentioned, is how difficult would it be to transition from a non-PQ temporary solution to a PQ, more permanent solution? And I think there's both a technical question there, but also an experience and learning question there as well. Maybe some of the work done on the non-PQ temporary solution would be relevant and informative, for implementing the PQ more permanent solution. Feel free to correct me if I got anything wrong, but… For a layperson's summary,

That's what I took away.

Gottfried Herold: Yeah, that's perfectly correct. But I mean, all of these questions depend on the scheme. There are the answers to all of… most of these questions depend on the scheme, of course, or how you use Sort of the encryption.

Loring: Any additional comments regarding that before we move on to the next topic? Okay, next we'll, pick up on the conversation regarding the Validator whitelist. Jannik has prepared some additional, information, which begins to tackle the questions, how do we prove withholding and key selling, and can these proofs be automated? So I'll hand it over to Jannik.

Jannik Luhn: Yeah, so, Loring is showing the table here I created after the discussion we had in the previous call. I try to understand them better for myself and organize it a little bit better for me, and maybe it's helpful for others too. I split it… I call them now confidentiality and availability attacks, instead of, key selling and withholding attacks. Confidentiality, because it's more broad than just key selling, I mean, the point is that the key is then not, yeah, secret anymore. It could be the committee itself that's, that's using the key. They could sell the key as a whole, they could sell key shares, they could sell even individual decrypted transactions, and I think confidentiality is, yeah, covers that a little bit better. And then withholding, I think, is a fine name, but…

In… to keep it, kind of… analogous to confidentiality, I called it availability attack, basically meaning that the key is not available at the time when it's supposed to. Yeah, and to the two questions, how to detect it and what to do about it, there's two, rows in the bottom. I think the content we already discussed in the previous call, basically, availability is detected by the protocol itself via timeless committees, so we can do… Yeah, slashing economic penalties, we can remove the, the mechanism automatically, or the publisher automatically, if you want to. So that's relatively easy. the confidentiality attack is in general, I think, yeah, undetectable. Maybe in some cases, depending on the protocol, there are…

like, things like snitching proofs, or, maybe you can slash them for… if you get ahold of someone's key share, but in general, these don't really work, or as circumventable by, using TEs, for example, or other mechanisms. So, I think we just have to live with them, basically, and then mitigate them via, yeah, social accountability, reputation, and large setups. But also, it's not that big of a deal, because the victims of confidentiality in this one-line affected parties there is basically only the user who explicitly chose, this particular key publisher, so it's bounded the, kind of. the risk, whereas the availability attack is much, much larger. A set of people are affected, even people who did not choose this key publisher.

For instance, transactions that come afterwards, in a block, or arguably even the protocol as a whole, because, the… Yeah, the chain gets spammed a little bit, because… People want to make use of the optionality they get from running this availability tech, but they can only do this very inefficiently, so a lot of space is wasted by that. But yeah, fortunately, since we can detect it automatically in the protocol, this is much easier to mitigate. So, yeah, nothing new there, just basically the summary of the, of what I took away from the conversation we had in the previous previous time.

Loring: And would it be correct to say that, kind of, the ultimate mitigation would be Exclusion from the whitelist. Thus preventing them from providing keys?

Jannik Luhn: Yes, yeah. I mean, ideally, you prevent it in advance, that's kind of the idea of slashing, right? That you make it expensive so that it doesn't happen in the first place. If you have to exclude them after the fact, it's arguably already too late, depending on the, the impact the attack had. But yeah, That's kind of the idea of the whitelist, that they only select, key publishers that are, Yeah, expected to behave correctly, and if they behaved incorrectly in the past, that's a good sign that they won't do that in the future and should be removed. either manually, via the whitelist mechanism that the validators just say, remove them, like, they don't vote on them anymore, or, as I said, in that case of availability attacks, that might even be automated if,

yeah, I guess we would still need some sort of threshold there that a single, accidental non-reveal, or even maybe censorship by some committee doesn't lead to that, but… Yeah, in theory, it could be automated. Personally, I'm quite happy with that, state so far. The main question I have for the whitelist is, is it acceptable by the community to, put this responsibility on the belly data set to vote on… to either vote directly on key publishers and select them, or to, select a committee that does that. Both might be… Yeah, there's arguments against either of these, you know, options.

Loring: Oh, wow. Does anyone have thoughts on… this table on the acceptability of the mitigation strategies, or… giving… That additional role to validators.

Gottfried Herold: I mean, who else should have that role, right?

Jannik Luhn: So it could be, in theory, also, ETH holders. We could do, kind of a coin vote, but I think that's way worse, to be honest.

Gottfried Herold: Yeah, yeah, it's much harder to sort of do… do in practice. I mean, you need, in order to, sort of, for the deterrent to be meaningful, you need to be… it needs to be kind of somewhat hard to get into the whitelist. So, yeah. And at any rate, I mean, most of our… most of all ETHIN circulation is staked anyway, or not most, but a significant fraction is staked anyway.

Jannik Luhn: So the difference is not… not as big.

Gottfried Herold: Yeah.

Jannik Luhn: I mean, briefly, I also thought about could we just let each, proposer make that choice? But that's also very annoying, because, then… You have, like, potentially very differing, sets of… key publishers, and maybe if you choose the wrong one, it takes a long time for you to get accepted. And if you're a key publisher, you need to convince every individual Validator, basically, to accept you. So, I think that's also impractical, and I think Validator voting's the… By far the most sensible choice.

Loring: Oh, boy. Jannik, you said regarding confidentiality attacks that the… Damage is bounded because users can choose which of the whitelisted Key publishers they would like to use, and… by choosing a particular key publisher, they are kind of accepting the risks which come with that key publisher and their stated model and their track record. We know that a lot of the users do not do their own research and go more on vibes alone.

Could you imagine a situation where a… Key publisher regularly engaged in confidentiality attacks, allowing them to frontrun or sandwich. But because they had sufficiently good marketing, or maybe, Connections to, popular, players. that… They would not, have that social accountability.

Gottfried Herold: I mean, it's kind of what happened in what's usually called Encatification, right? outside of the Ethereum world. Something… somebody used to be reputable, but I don't know, business models change, and then they basically drop out of their… of their game and sort of try to take some profit with them, as they basically drop out from being socially reputable.

Jannik Luhn: Yeah, I mean, true, can happen.

Gottfried Herold: Yeah. I mean, my expectation would be for the choice of, sort of, provider, would be that wallets come basically pre-configured with a set of… with a default set. That would be the expectation they would see in reality. Probably wallet providers, maybe hardware wallets or whatever, would pro… might actually do such a service themselves. And sort of hardwire their own provider into their sold… into the wallets they sell, into their products, in particular for hardware wallets. It's kind of a reasonable business model, actually. To sort of default or nudge people into this… into using their services this way.

Jannik Luhn: you could make the same argument, Loring what you said about, private Mempools as well. They kind of… their value propositions that you don't get Frontrun if you use them. They already achieved pretty big, I'm not sure if monopoly is the right term, but,

Gottfried Herold: You know, legal police policies.

Jannik Luhn: So they would be in a position to do that, to kind of, I don't know, front-run every 10th transaction, or… front-run 10% of their, yeah, extract 10% of their front-running potential, and they won't do that.

Gottfried Herold: Yeah, I mean, the question is, in some sense, very, very strongly tied to the… I think. to the, moating or to the market design to sort of enter the whitelist. Because the question is, I mean, okay, if things go down, how easy is it for a newcomer to enter the market in case a legally of, sort of, bad, decryption services actually goes rogue? And this is strongly tied to how the actual market or the voting mechanism for whitelist inclusion works. I mean, do you vote on each individual whitelist participant individually, or do you vote on sets of them? And there is a lot of questions, actually, for this design, and I think It matters a lot.

Jannik Luhn: Okay, interesting. I always thought the voting mechanism, like, the details don't matter too much, but…

Gottfried Herold: Yeah, I mean, if you say you vote on a whole set of things… I mean, the problem is if you vote on… this is the set of whitelisted addresses, then the problem is that if you have, I don't know, 20 different candidates, you have 2 to the 20 different options, which means that a single mo… if you sort of go with a single minority, or a simple minority, then actually, basically you don't… you might not need a whole… a big fraction of total Each stake to get your wish… your wish set in, for instance.

Jannik Luhn: Cool.

Gottfried Herold: So, yeah, you have to sort of… or you do some kind of ranked voting, you want… I mean, what's the threshold? Do you want… you don't… it's not clear you want the best of those to get in. I mean, how do you do it? You propose something, and if at least 50% of E sort of says, hey, yeah, this is a good… a good, sort of set, then yes, I get in. But that also means that most… since most validators might not care about this, and I mean, a lot of these validators run actually in some automated stuff, I mean, I don't know, an at-home staker, maybe you get a future where at-home staking becomes much more…

present, let's say we do change issuance or whatever happens, the whole sort of staking, landscape might change in the future. You have a lot of home stakers, and I mean, your regular home staker does not want to care about, hey, there is this new, I don't know. company which provides decryption services, hey, please vote for us, all of this needs to be done manually, they just want their hardware to run, and… And not deal with it manually. So it's kind of hard to get people to vote at all. Not so much to vote pro or con, it's hard to sort of get people to vote at all. So how do you actually do your set quora for this? Do you not do… there's a lot of questions, actually, here.

Jannik Luhn: Yeah, so maybe I should, try to… write this down a little bit, to the options we have there. Intuitively, I would say, yes, we do want to have delegation to avoid this, so that home stickers don't have to make that choice. And for the voting mechanism itself, I would have said, each vote is independent, and there can be an infinite number of publishers, so… and as long as one key publisher, or each one gets more than 50%, they get accepted. Because I don't really see,

Gottfried Herold: 50% of… okay, so you just have yes votes or no vote, and you want… you need a 50% of all. You don't have… you don't have against votes. And not war room.

Jannik Luhn: No, like, no vote is against… Okay. Always. To keep it simple.

Gottfried Herold: So, but this means you cannot, sort of, remove people from the whitelist, right?

Jannik Luhn: You can buy… I mean, it has to be, kind of, I mean, the Validator set potentially changes, so it always has to be updated anyways, right? So, kind of, the past N validators, are the set of voters. And in that, they… maybe they're more with every blog that they publish.

Gottfried Herold: Well, so you mean you re-vote, so you basically keep voting?

Jannik Luhn: Yeah.

Gottfried Herold: Not just for changes. Now, that's a lot of bandwidth, potentially, but okay.

Jannik Luhn: That's true. Okay, yeah, I see that's a good point. I should, think more about this, and… Yeah, write something down for the next call.

Loring: Couple of related questions. Jannik, did you have… A ideal number of key publishers, or a maximum number of key publishers in mind?

Jannik Luhn: So, I don't think there should be a maximum number, I don't see why there should be, as long as… I mean, the only, like, from the protocol perspective, the only thing that matters is, that the key publishers don't engage in these availability attacks, and any, key publisher that doesn't do that can be accepted. I don't see a reason why that should be limited. Yeah, from a pers… like… Competition is always good, so the more the merrier. How many it's going to be in practice. I don't know. Probably not too many, maybe 5.

Loring: and would… I'm not sure exactly how to phrase this, but the gist of it is, should the validators have… preferences about… Who should… Be a key provider, or what type of key provider should be accepted above and beyond just a commitment not to engage in availability or withholding of tax. For example, Should there be a preference for… Key providers which provide the service as a public good, as opposed to, doing it on a commercial basis. Should there be a preference against key provider or key publishers? Which are… also run by a wallet which has a tight coupling? Or do you see that, validators should just kind of certify

They don't engage in availability attacks, that's good enough, we don't think about anything else.

Jannik Luhn: I would say the latter, to make it as easy as possible for them, and that's already difficult enough, I think, to predict in the first place. In advance.

Gottfried Herold: I mean, from a protocol perspective, the thing that we want to defend the protocol against is essentially someone basically just making a new basically decryption service for each individual transaction, and then withholding or not, basically doing an optionality attack. That's basically the attack that you want to defend against. So the barriers can and should be actually very low.

Jannik Luhn: Yeah, I agree.

Gottfried Herold: And then selection of the actual, sort of, service providers, you know, done by economic… Means.

Jannik Luhn: I mean, there could even be, an… like I mentioned, slashing is possible for, for recording. And there could be an optional stake, and new key publishers might have to put a lot of stake up there so that… to convince validators, which can then be reduced over time once they've gained trust by the validator set. So that might be another parameter to take into account.

Gottfried Herold: Yeah, slashing for withholding is a bit problematic, because then, basically some kind of blackout, or some internet outage, or this is sort of… Sort of puts a high operational risk.

Jannik Luhn: Yeah, but I mean, these are supposed to be professional, it's not like,

Gottfried Herold: That's.

Jannik Luhn: Not the equivalent of a homestaker.

Gottfried Herold: True, true.

Loring: Any other questions or comments? on this topic. So the final agenda item for today is achieving censorship resistance for the original EIP-8105, trusted set, and Anders provided this Note… Looks like it was last edited a week ago. I have not actually had the time to review it, so I can't provide a summary. But if anyone on the call has reviewed it. and would like to give a summary, that would be wonderful. Unfortunately, Andres is on holiday this week, so he's not here to share it himself.

Jannik Luhn: Yeah, maybe we can do that next story, next time, when he's back, to… Give him the opportunity to, to present it.

Loring: In that case, I will just point out that the link is here in the GitHub issue, and invite all of you to take a look And reply… here. Did any additional topics come to mind during the course of the discussion? In that case, I think we'll… we will keep the meeting short for today. Thank you to everyone who joined us, and, if you are interested in joining the Encrypt the Mempool, MarComms working group. That will happen one week from today, at the same time, and if you are interested in joining the next Encrypt the Mempool tech working group.

That will happen in, 2 weeks from today at the same time. mercy, I see you have your hand up, please.

Mercy Boma Naps-Nkari: Yeah, sorry, sorry I joined late. I wanted to also point out about the SL spec. In case anyone wants to review that also.

Gottfried Herold: Can you point to what exactly you mean?

Mercy Boma Naps-Nkari: Okay, let me gather link.

Loring: Is it this one?

Mercy Boma Naps-Nkari: No, it's, the EEO spec I opened,

Loring: Oh. Yes, wonderful.

Mercy Boma Naps-Nkari: Yeah, I shared the link in the chat.

Loring: Wonderful. Let me just copy that and bring it up for everyone to see. Yes, go ahead.

Mercy Boma Naps-Nkari: No, I just wanted to point it out that it's still open, in case maybe it's… there is… should be an update so that I can update it or anything, or someone wants to review it in general. It's still in basic trough.

Loring: Does anyone have a comment or an update? Okay, I think that it's probably best to bring this up as part of the next call, when Justin is back, since he has been doing a lot of the project management aspects for the Encrypt the Mempool, but it's wonderful to see that, Justin Traglia, has been contributing, alongside you, Mercy. It's great to see that this is advancing.

Is there anything else anyone would like to share or discuss on the call? In that case, have a wonderful Wednesday, and see you all in one week for the MarComms Working Group, and in two weeks for the next Tech Working Group. Have a great day. Thank you for joining.

Anthony: Thank you.

Jannik Luhn: Bye-bye, thank you.

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