Encrypt the Mempool Call #6

Transcript

Justin Florentine: Eureka!

Loring: Hey!

Justin Florentine: What happened?

Loring: I didn't turn it out.

Justin Florentine: I don't know. I… I don't know what happened there. I… I messaged Pooja. And complained, maybe she just fixed it out, fixed it on the, on the… on her own there.

Gottfried Herold: I mean, the error message I got was that you were in another meeting, which is kind of weird.

Justin Florentine: Yep. Yep, I got that message too, which is weird, because it… I guess I'm not the host. Hello, everyone! Welcome to Encrypted Mempool number 6. Thank you for…

Mark Holt: Or… control.

Justin Florentine: thank you for, putting up with the waiting room, and, I'm gonna talk to some EF cat herders about that, figure out if we can get a little bit more of a reliable startup to our meetings. I'm your host, as ever, Justin Florentine. Thank you, everybody, for joining us. We have a fun agenda, Cued up. I see a lot of new faces, so welcome, everybody. Welcome to EncryptoMempool. Post the… let's see, let's see, let's see… EncryptoMempool number 6. Here we go. Issue 2118… Posted the link to the agenda in the chat. We can just get right to it. Mercy, you are in the right place. It's not just you, buddy. Alright, let's see… Yannick, I'd like to briefly introduce post-inclusion ordering, a research idea we're explaining. Fun! Okay, great. We'll tack that onto the agenda. So, for starters, CL dubs. We don't have any CL dubs, we still need CL dubs.

They're real busy with ePBS right now, so I have, I have talked to some. And, yeah, they're just kind of busy right now, so, you know, keep your eyes peeled for anybody that wants to contribute on that front. We specifically have… needs as far as writing CL specs and getting them, added to reference implementations. On that subject… Oh, Lori! Hi! Go ahead. You have your hand up, sorry.

Loring: Yeah, on the topic of consensus client teams joining the call, I was just DMing with Matt from Lodestar. He said he would love to join, but he is on a plane at the moment, and he'll try to join, in two weeks for our next call.

Justin Florentine: Awesome. Feel free to put us, in touch via telegram or otherwise. Matt at Lodestar. Cool, cool, cool. Speaking of things that we need from a CL perspective, I created the Lucid PM repo, which, was pretty vibe-coded, but, you know. There's a link to it in the agenda, it's in my own personal repo for now, we'll move it somewhere else once it becomes… once we scrape some of the clot off of it. But it kind of collects, it's basically a documentation repo that has collections of, you know, pointers to PRs and specs and things that we're missing. So, if you take a look at it, maybe I should share my screen. So here it is. It's just JFLO, Lucid PM for now.

Right here is kind of our status at a glance. We have an EAP and a draft PR for execution specs, and that's about it. You can see a bunch of things right there for consensus specs that are missing. So… Open to feedback on this. This is just a very loose, like I said, Claude helped me get this organized. Feel free to open PRs into it, comments, issues, whatever you think we need as far as coordinating the real technical work that needs to happen to get us to SFI. Any questions on that? comments, concerns? Mercy, do you have your hand up?

Mercy Boma Naps-Nkari: Yeah, sorry, good afternoon. Good evening. I wanted to comment on the sales spec. Because I was looking at the spec, and then the current, the, the, the, the parent is his, which is… which provides us with FOCIL inclusion list. Why? glowers, which is under it provides BTS, and then the execution pill would be it. So, I wanted to know if it is okay for me to, like, scaffold this CL spec under EIP81… It's full.

Justin Florentine: Yeah.

Mercy Boma Naps-Nkari: And then… Another thing I also want to ask is about, I want to first, like, work on the standalone pieces, like. without the EL, co-design. Like, the SSZ, the standalone pieces, I… was able to, like, map out is the SSZ container, the… inclusion list, and then the payload, extensions, and then the Lucid Key, votes. So… what… I feel like, the pieces that generally requires, like, a co-design with the EL spec, which you're currently working on, is the engine API V2 shape, and then the recovery, flow setup. So, I would like to know… if I can start the standalone half while in parallel with the PR you're currently working on, or should I just hold off until the EL ticket, decryption flow and fee surface are stable?

Justin Florentine: I think that… I don't see a problem with that. I mean, a lot of that stuff doesn't require specs, right? That was your… that's kind of your point, right? Like, a lot of this stuff doesn't require specs, and it can be worked on. What client were you going to do the work in?

Mercy Boma Naps-Nkari: So, I wanted to map out the spec… the PR on the spec, the Skeletal path, then I will kind of, like, pick a client to make the implementation, and just… I just wanted to know if it's okay to work on the standalone first, or wait till your own PR gets… Most solid, sort of.

Justin Florentine: Oh, I see. Are you talking about on the EL side, or on the CL side?

Mercy Boma Naps-Nkari: The CO side, yeah.

Justin Florentine: Oh, the CL side, I… I would defer to your judgment on that, honestly, and this is kind of why I've been asking for CL judges… for CL devs to participate, is like, I don't really know how those specs work, or what the best practice is, so I would just say go for it, you know, if you don't mind. I think we're so early in the process, we kind of have to be willing to not be precious with our code and throw stuff out. So, you know, if you're comfortable with doing work that… Might not, you know, might not be kept. I am unfortunately not qualified to coach that. I'm sorry, that's not a great answer.

But I guess what I can say is that I'm not planning on doing the work that you're talking about on the CL side yet, and I don't know of anybody else, so if you want to go first, go for it.

Mercy Boma Naps-Nkari: Okay, thank you.

Justin Florentine: Yeah, sorry, I know that's not a great answer, but, Let me know how I can be better. Loring?

Loring: Two questions on different topics, and we'll take them one at a time. Two weeks ago, Justin, you said that Erigon may have a, unique ability to play a role in writing the client specs. Because Erigon 3 is both, execution and consensus. I noticed Mark from Erigon is on the call. Is it worth you guys jamming on that, for just a second?

Mark Holt: Yeah, yeah, yeah, yeah, yeah, yeah, no, no.

Loring: Literally jamming on that.

Mark Holt: Yeah, that was… I mean.

Justin Florentine: Try again, Mark.

Mark Holt: Can you, can you, can you, can you, can you, hold on. Can you… can you hear me now?

Justin Florentine: Yes.

Mark Holt: Yeah, so I managed to have the browser and a, and a Zoom session open at the same time. Yeah, I mean… we can… we can get… I'm a little bit reluctant to get involved in the CL… speccing stuff, just because… we're not… We're not, we've… we've not… our general approach to the CL is wait for the specs to appear, and then, And then try and implement them. Now… It… it would be… I mean, maybe this is a good opportunity for us to try and get a bit more involved earlier on. Because actually, yeah, we will… we can do the EL and the CL both at the same time. But it's a bit like the previous answer, because I haven't got… because I've got a lot…

I don't think anybody in Erigon has been particularly involved in the CL specking process, so it's… we can start trying to do it, but I can guarantee that we won't be following best practice, I think. Well, if you see what I mean.

Justin Florentine: I see what you mean, because I'm in the same boat, buddy.

Mark Holt: Yay. So… Happy… happy… I mean, because it would be good to get this going, and I think we can't get the mempulse… we can't get this working without a CL implementation. So… I can… I can try and bastardize the protocol, or get somebody else to. I'll talk to our CL guys, try and persuade them to, to get involved. So… But yeah, I mean…

Mercy Boma Naps-Nkari: So, I think I just have to, like, come in a little bit.

Mark Holt: Sure.

Mercy Boma Naps-Nkari: So that was why I was asking if it's okay for me to start, start the SSZ containers, and then the inclusion list, and then the payload bid extension, then the LucidKey, timeless vote. Because all these are CL spec. I feel like it makes more sense to have a spec on the CL side, then the CL clients can know what actually they want to implement.

Justin Florentine: Yeah, so you're saying you would get some of the low-hanging fruit, as it were, out of the way, and so that when the CL devs do need to come in, they won't have to think about those smaller, self-contained things? Is that what you're saying, Mercy?

Mercy Boma Naps-Nkari: Yeah.

Justin Florentine: Yeah, I like, I like that approach.

Mark Holt: Yeah, and if you're gonna do that, I'm happy to get involved with looking at it from a, how would we… how would we stick it into our CL? Eventually.

Mercy Boma Naps-Nkari: Yes, that would be really helpful, because if I get it out, I will need someone from the CL to actually, like, review it, and then make some.

Mark Holt: Yeah, yeah, yeah. So, I mean, if you're going to spec stuff out, I'm happy to look at it and try and implement it. As I say, with the caveat that probably… when a real CL developer with more experience, they'll probably point out stuff that I've not quite got right. But, I mean, what I will be able to do is to say, right, here's our implementation, if we do this, it looks like it'll work. And it'll work for both the CO and the EL side. So, yeah, I mean, happy to get involved with that. So maybe, if you can just, As you get specs, get in touch, and I'll start looking at the implementation of it.

Because I'm guessing where we are with this at the moment is we just need to try and get something working. Even if it kind of… even if it morphs into something completely different over the course of time, which is kind of the expected process, I think.

Justin Florentine: Sure is. Happy to, so there's a number of places where y'all can stay in touch. We can… there is the, Encrypted MedPools channel and Discord, and there's also a couple telegrams. We'll make sure that both of you are invited to those. Maybe… Yeah, great. Lauren, your hand is still up. You had another follow-up question?

Loring: Yeah, There may be the possibility to unlock up to $10,000 for some type of incentive, possibly a bounty to kickstart this consensus spec. And, It's something that I would need to work together with someone else on in the next week, but if anyone would be interested in Helping me outline a bounty so that, It's kind of… pointed in the right direction, I would be very interested in doing that, and I can't guarantee the funding, but, we can work on a proposal, and if it's accepted by ShutterDAO0X36, then that could be some money to incentivize some action.

Justin Florentine: I think, I love that, first of all. Yes and. We kind of have the same problem that we have elsewhere, though, where none of us are quite authoritative in judging the results of a bounty to determine that it should be paid out, right? Like, I don't… I wouldn't know how to correctly define the success criteria for the bounty. Because, again, I don't, I don't, dabble in CL specs. But this is another thing that we can run by the CL people that we're gonna harass to help fill in these gaps.

Loring: Sounds good. Thanks.

Justin Florentine: Cool stuff. Cool stuff.

Mark Holt: I think in general, if we could get something that just flows, it'll make it easier to also For people to figure out the various timing things that are involved in this? Because it just… it feels to me like this is something that if we can make Whether it's right or wrong, if we can make a flow work, then it becomes a lot easier for people to reason about what the What the preferred option is. So…

Justin Florentine: Okay, I lost my agenda here… Do-do, too many… Sorry, y'all? Okay, cool. Cool, cool, cool, cool, cool. Next up. Okay, so we showed off the PM thing, we talked about sealed up. Kurtosis stack for sandwiching! Yes, that's right. We vibed up a thing. For those of you that are familiar with Kurtosis, it is a Docker suite for building a complete network and being able to deploy stuff to it. I made one that does sandwich attacks. So, this could be, like, our little test bed that does stuff. Unfortunately…

I did it on Fusaka, because the Glamsterdam stuff is so in flux right now that I wasn't able to really get, up-to-date consensus layer running and activating Glamsterdam and operating. So, that's kind of a big deal, actually, because we really need to develop, We really need to develop against ePBS, because it's a critical part of the design. And so, you know, this is, this is, good for kind of demonstrating sandwich Attacks and how it works, for Fusaka, but this will need to be maintained and updated as soon as Glass starts becoming, available. Again, this is in my own private fork. It is very rough draft. You can see… that it's been very heavily vibe-coded, but that's… that's our reality in 2026. So, encourage people to check it out, pull it, play with it, break it, open PRs, tell me I suck at Python, all that fun stuff.

Questions, comments, concerns?

Mercy Boma Naps-Nkari: private.

Justin Florentine: Oh, no! Good comment! Alright, I should probably make it public. I'll do that. Danger zone, yeah. Yeah. Good. Please hold. Anyway, moving on. I'll get this, I'll get this unlocked and shared with, shared with folks later. Thank you for checking my work, Mercy. Next up in the agenda, though… is…

Nope. Alright, that should be public now. Oh, here we go, I can start sharing again…

Gottfried Herold: No, key release fees.

Justin Florentine: Can you see it?

Mercy Boma Naps-Nkari: Yes.

Justin Florentine: Alright. Your weapon's free, Mercy, go get it. Alright, Kurtosis, da-da-da-da-da. Next up, actual design discussion points here. I don't have a… so let's open the discussion here, talking about key release fees. Mercy had some questions, actually. Thank you for looking at the implementation. First of all… And we had a question about… oh, it's over here. Yep. We had a question about… How key publication fees are billed. I asked Anders to join. I don't know if he's going to be able to. Let me see if he actually had a chance to comment.

Gottfried Herold: I wrote on Telegram that he wouldn't be able to join.

Justin Florentine: Okay. Okay. So, the key publication fee is intended, essentially, for, Other people that want to serve as decryptors. It also overlaps with the bundling functionality a little bit. Right. So a bunch of us could get together and say, hey, we agreed to let, this decor provide the key for us. And they'll provide a key that covers all of these messages in the bundle. And so… When it comes down to the spec here, we need to figure out exactly… how does that get… get built? And Mercy brought up some pretty good, some pretty good questions here that I don't know that I have a great answer for. I think… The key publication fee… Needs to be paid out of…

I guess the question is, is does it impact the headroom for the gas, right? And I think it must. But I'm not quite sure how to express that in the spec. So I guess for starters, is anybody else confused about key publication fee and how it's… represented in the Lucid spec.

Gottfried Herold: I mean, you have this kind of different kinds of fees, and this kind of if, this maximum taking, and so on, which is kind of confusingly written, I think. I mean… Because you sort of add a lot of variables that are sort of, if you just look at them in isolation, it's kind of a Looks like… It's redundant in some sense?

Justin Florentine: Okay.

Gottfried Herold: weird logic that, sort of, this max fee, and sort of… it's just a bit of a weird… It's just not always clear whether this max fee, I mean, what this even means, like, the maximum fee you pay for what, and so on. It's more of… it's more about a writing issue. I think it's more of a writing style issue, personally. Just as a field, some kind of feedback, but…

Justin Florentine: I think that's correct, and I think I agree with that, and I'm just not quite sure how to, Simplify it in such a way that it answers the question here.

Mark Holt: Sorry, can I just ask a dumb question? Is this intended to be… It'll get taken out of gas somehow, it's a gas fee.

Justin Florentine: Yeah, it needs to come off the top, right? Because we're not introducing a new… Fee.

Gottfried Herold: Yeah. I mean, it's an extra payment mechanism. It's kind of unrelated to gas. I mean, you could also denominate it directly in ETH, I guess?

Justin Florentine: I mean, it is and it isn't, though, because to Mercy's point is that, like, it needs to be subtracted at some point to figure out, like, how much gas did you actually pay for as you. you're calculating, right? And that's, I think, the confusion here. Am I summarizing this correctly, Mercy?

Mercy Boma Naps-Nkari: Yeah, yeah.

Justin Florentine: Okay.

Gottfried Herold: I mean, it sort of, to me, it would make sense to sort of treat it as some kind of separate object, in a way, from the gas.

Justin Florentine: Hmm… Yeah, yes.

Gottfried Herold: Sort of not… sort of just not conflated with the gas fee at all, because, kind of, it's not really… it serves… it serves a completely different purpose. It's more of a transfer of ETH conditional on something than a gas fee.

Justin Florentine: Right, because it's not actually paying for gas, but it's impacting how much gas you have, right?

Gottfried Herold: Yes.

Justin Florentine: So, so, so the, the… huh. The amount that you're paying your key release person could potentially threaten whether or not your transaction goes through. Like, if you're cutting it, if you're cutting it really close.

Gottfried Herold: Yeah, exactly.

Mark Holt: Because you've basically not got enough money to pay for the gas, because you've taken…

Gottfried Herold: Yes.

Justin Florentine: Yep. And if we carve out a separate field for a new fee, I… 8. I haven't thought through, like, the cryptoeconomics of that. Right? Like, you… when you do that. You're formally describing, effectively, another market, right?

Mark Holt: Yep.

Justin Florentine: But the market already kind of exists! Like, the market exists as soon as people start offering to do this. Whether we're taking it out of max fee for gas. Or a different field.

Gottfried Herold: I mean, it doesn't change anything, really, in who pays what, it's just a matter of how it's represented.

Justin Florentine: Yeah.

Mark Holt: Well, yeah, and the spec's clear enough, so as a client author, you can work out how to charge it.

Gottfried Herold: Yeah.

Justin Florentine: So, maybe what we should just do is rewrite this a little bit more clearer, so that it… Answers the question as to whether or not we're overshooting by top-of-block fee plus the keep-up fee. And we should just write it so that, look, all these things come off the top right from the beginning. And, yes, they impact the gas. And… Dealing with that as a exercise for the wallets. And if we don't like that, then we treat that as a design decision that we have to iterate on.

Mark Holt: Yeah, well, it will become a thing for the walls, which will then… will then mean we'll need an RPC for estimating it.

Justin Florentine: Right.

Mark Holt: So, it'll go around, and that's my… looking at this, I'm thinking, yeah, this is another estimating RPC. So, it'll end up.

Gottfried Herold: why… why would you estimate anything here? I mean, the fee you pay for the Kiri will…

Mark Holt: Whoa.

Gottfried Herold: It means there's nothing… it's basically given, there's no uncertainty about it.

Mark Holt: No, no, but what it means is if it becomes a wallet responsibility to calculate it. They'll likely want to call an RPC to know what the number is. Because they're really, you know, the thing that they're doing is asking. is this fee enough to cover my gas, is what they do.

Justin Florentine: Will you reveal my key if I pay X?

Mark Holt: Yeah.

Justin Florentine: So, like, you have…

Gottfried Herold: You mean, oh, you mean for the, for the release, for the release,

Justin Florentine: Yeah, the key pump fee, right? But wallets need to know to include that, which means they need to know how much it is, which means they need to have some way of communicating across the network to the people that are going to be doing the key release, so…

Gottfried Herold: Damn. But at the end of the day, this is more of a question about how to communicate with, sort of… I mean, in some senses, those key release entities are completely off protocol. By design.

Justin Florentine: Yes, but the key… the amount to charge for it could be on-chain. Other protocol, but on-chain and available.

Gottfried Herold: I'm not… yeah, I'm not sure… Sure about that, actually. Because, I mean, it's not even clear whether this kind of carrying lease thing should even be a public service.

Justin Florentine: So, okay, hot take here. This is another thing that I wanted to run by the room anyway. Key… the key release fee? It is kind of, a feature of bundling. Is that true?

Gottfried Herold: not necessarily… it's not reliant, it's not tied to bundles either. You could just have a single key, I mean, and sort of ask anybody else to sort of release it for you. I think it's actually kind of orthogonal to bundles. Because even in a bundle, even in a bundle case, you don't have one key for the whole bundle, and you still, in the bundle case, you still use separate keys for each individual transaction.

Justin Florentine: Okay, good, good, good, good. Okay, so it's orthogonal to bundling. But it's also a necessary feature.

Gottfried Herold: I mean, otherwise you just don't have incentive for it, and, I mean, there is a nice application, actually, which is described, I think, in some of the rational, I think, where you basically use, And I think it's the top of block fee… yeah, no, no, let's not forget about it. I think in the… I think in the bundling case, you could, in some theory, even get around it by basically setting the top of block… by basically using the top of block fee to sort of… Use the payback from the post-block fee to pay the bundler. There's some kind of weird things you can play, but yeah, no, it's kind of orthogonal to… it's basically, it's largely orthogonal to bundling.

Justin Florentine: Okay, so we need to sort this out, though. The reason I brought that up is because I was wondering if we factored out bundles to a separate EIP, if that could give us a lot more room to slim this down and simplify, you know, 8184 as it seems. That may still be true for bundling, but it doesn't help us for key publication fees.

Gottfried Herold: As far as I can see.

Justin Florentine: Great. Okay. So, I think I, I think this is maybe as, like, a offline action item. Who… does anybody want to work on simplifying this language? With me and or Anders, if he's… if he's available. If no one's ready to volunteer now, that's fine. But hit me up. Out of band, to contribute. key publishing…

Okay. Alright, that was unsatisfying, but you know what? That's… that's design. It's gonna happen, you know? you're gonna find a design gap and go, okay, I guess I gotta work on that. Speaking of which… Optionality. We talked about this a little bit last session. And, Gottfried, thank you for… I don't think you had published your piece yet. During our last meeting.

Gottfried Herold: That's correct, yes.

Justin Florentine: For those that had not seen this, this is really good. This is, Gottfried… nope, that's not it.

Gottfried Herold: It's on East Research, it's on East Research.

Justin Florentine: There it is. Thank you.

Gottfried Herold: Just a… just a bit of a… just a write-up of all of the kind of criticism, just to collect everything in one place.

Justin Florentine: Yes, and it's very…

Gottfried Herold: and some aspects, I think, were kind of not really that in front of mind for some people, so it was probably a good thing.

Justin Florentine: Yes. And one of the subjects that you mentioned here was optionality, I think.

Gottfried Herold: Honey? I mean, yeah, there's various ways of optionality. I mean, there's the optionality that we all know and love, or hate, or that is kind of unavoidable, given the current state of the art, which is that the key releaser, which, in case you want to exercise optionality, is typically yourself, so… in the main case, we talk about self-key release, where basically you just refuse to release your key. And you can do that depending on whether other people boots, release your key or not, or after seeing other skis.

Justin Florentine: Yes. I think one of the things I want to discuss with the group is probabilistic front-running as a form of optionality, right?

Gottfried Herold: This, yeah, this is an implication of, yes, this is one way of utilizing this to still extract MEV. I mean, it's discussed in the Lucid EIP to a great extent, this is just much more, with formulas and probabilities and everything.

Justin Florentine: Yes. So, I wanted to talk to us about, maybe reframing this not as a criticism of Lucid, but actually just, this is a spam problem. I think… I think this… this could happen for lots of reasons and lots of ways, and we actually see this on optimistic networks like Base, right? And Solana. We see this probabilistic front-running As it is kind of a known thing, so, How should we prioritize this as a design problem to fix within Lucid, as opposed to treating it like a spam problem and pumping on it, to use an Americanism?

Gottfried Herold: I'm not sure what you mean by spam problem. I mean, it's not… I mean, to be fair, I mean, I think Andres is not here, so probably could answer it better, but, Essentially, due to the fact that we do not have encrypted mempools, this optionality is just there, it's basically the best we can do for now, so I think we cannot solve it, simply put. This will be just an issue. There are certain mitigations you can do, and the main mitigation that Lucid does is, top of block fees, so basically you punish people who sort of do not reveal, in a way, and you can sort of amplify the punishment, or try to amplify the punishment via bundling. Those are basically the…

The mechanisms that we have in place to sort of disincentivize this, and… I don't think there is much more we can do.

Justin Florentine: Okay.

Gottfried Herold: Viewing it as a spam thing, basically, would just mean… I don't think… I don't like it sort of treating it as a spam thing, because treating it as a spam thing would just mean that, yeah, we have more transactions that do not do anything, that… or maybe some people sort of reserve gas, and And they don't actually put out transactions, or it's kind of wasteful for the chain itself, so spam sort of treated like a problem for the chain. And that's kind of not true, in a way, because they pay gas. In fact, they overpay gas. The problem really is that it still allows MEV extractions. Which is precisely what you want to sort of avoid. So, it's kind of… I think phrasing it as a spam thing is not…

Not terribly helpful.

Justin Florentine: Okay. I see your point. Okay. Well, I think if we're gonna accept this as kind of just not, you know, out of scope for Lucid, I don't really care if we cast fighters spam or not, because it's out of scope, so…

Gottfried Herold: No.

Justin Florentine: I'm gonna concede that.

Gottfried Herold: anything. We can't do anything about it anyway. Right.

Justin Florentine: Yes.

Gottfried Herold: Realistically.

Justin Florentine: So what other forms of optionality, did we want to… discuss, I guess.

Gottfried Herold: I did not put it on the account, I don't know.

Justin Florentine: No. No, no, I just wanted to present… I just wanted to present it as a broader discussion.

Gottfried Herold: Yeah.

Justin Florentine: Because there is optionality in Lucid, and I don't know that we're… and I think probabilistic farming is a good example of it, but anytime you can withhold a key, you're going to have that optionality, so… Yeah. Is this a deal-breaker, right?

Gottfried Herold: I mean, this is the basic question that, in the end of the day, ACD has to answer, whether Lucid gets CFI or not. Because this is really the… the issue with Lucid, and that's something we cannot solve. I mean, the main sort of starting point for Lucid, or sort of the design rationale for Lucid is I mean, we do not have threshold encryption, that is good enough, so, we will always have some kind of optionality without these cryptographic tools. Those it is kind of the best we can do, but it has this optionality issue. Whether, sort of, this is a deal-breaker, then, well, then, well, then there we are, and we won't have anything. That's basically just the reality of the situation.

Justin Florentine: Okay, so I can actually take that to ACD, and we can get some clarity on that.

Gottfried Herold: Yeah. So, this is… at the end of the day, this is really… The main… that's the main issue, and it's always been kind of… there, and kind of open and everything. It's not… it's just that it's something where… just something… it's just a downside of Lucy that we have to accept if we want anything.

Justin Florentine: Okay. Cool. We'll talk to people about that, and we'll see, we'll see what the vibes are.

Gottfried Herold: No. The more interesting kind of aspects of the… where we could potentially do something are actually the other option… the other optionality things. I mean, this kind of classification of optionality into probabilistic frontrunning, I mean, this probabilistic frontrunning is just a way to exploit optionality. On the design side, there is, like, the other sort of optionality things, which is called builder optionality, which is a bit more interesting, interesting, not in the sense that it's as bad as the reveal optionality, where the Key Provider basically fails to reveal, but this kind of builder optionality, which is something that at least may be amenable, or where the design may actually be able to do something about it, which is essentially related to these PTC tie-style votes.

I mean, bear… in some sense, I mean, the problem is, to some extent, that we are using, just to explain to those who did not read this, I mean, we are basically using a FOCIL-style mechanism to force inclusion, so basically, once you reveal your keys, we… force inclusion into the next block. We have to do that because the… the transactions are not decryptable by anyone, so we have to actually now execute them. Yes. Obviously. And in some sense, this, we use Fossil, and Fossil is a mechanism that basically ensures that if the On a ski provider basically makes it widely available, then the PTC votes will all say, hey, this was available, and so we can reasonably force the next included to sort of include it, provided everything works out, that things decrypt correctly, and whatnot.

Now, the problem is that, the FOCIL as a mechanism itself only makes sure that if you provide everything, then you also get included. It does not say anything about the converse. And the converse in this case would be, if you do not make everything available, you do not include it. But observe that, for Lucid, which, for Fossil, which is purely a censorship resistance mechanism, this doesn't matter. However, for Lucid, this means the following. Let's say you have some key that you never release, except to the builder. then the builder could, if you do not have any kind of thing for the converse, could just say, hey, look at what the other keys are released, and depending on that, yeah, I have seen it, so I can just include it. So you have to basically constrain the builder in some way.

To make sure that, sort of, whether you must not release keys that you have… must not include transactions for which you… for which the keys were not, sort of, made widely available. The problem is that you… Basically, would need to have, in order to make this kind of, in a really secure and safe way, which leaves the builder no free choice, essentially would need to run some kind of consensus protocol on which keys were released and which were not. Either you add another extra round, or you basically, accept the fact that there will be some wiggle room. So basically, if some keys are sort of made sort of only somewhat available, then the builder has a choice. And this, in fact, yeah, this gives you…

Some choice for the builder. And this choice for the builder is another form of optionality, which has other applications that you can sort of use them. They are probably not as bad. But they are still there. And there are ways to sort of mitigate this problem, at least, which would be, to, in particular for the PTC, case, would be to actually punish, equivocations of the PTC vote. Well, maybe vocations in the PTC boat, sort of excavate the problem. Or…

Justin Florentine: And this punishment would be because they exploited that, equivocation leniency, is what you're saying, right?

Gottfried Herold: Yeah, I mean, this is one… I mean, you do not really need the vocations, but if revocations make it easier. Because what you can do is, in some sense, what the current Lucid proposal basically says is that if more than 50% of the PTC voted for it, then you must include, and if less than 50%, if more than 50% voted that they did not see it, you must not see it, roughly speaking. The problem is there's some leeway, there's two sources of leeway. One leeway is that, there is sort of a distinction between they've seen it early and they've seen it late, which is sort of enough to actually already give you some builder optionality, and the other leeway comes from

PTC members who actually advocate, so they vote for both, they have seen it and they have not seen it. And those evocation votes basically count towards both options, and there's no punishment for it. And this makes better optionality easier to exploit and worse, and we could… we could simply at least disincentivize it easily by adding some kind of penalty for evocations.

Justin Florentine: Okay.

Gottfried Herold: So, this is a bit more interesting than the other optionality, not because it's worse, but it's because there is actually some things we can do about it.

Justin Florentine: Nope.

Gottfried Herold: On the design side.

Justin Florentine: I'm gonna talk to Potuz about this. But I'm gonna talk to POTUS about this, get his thoughts on it, since he's needy in Wonderland.

Gottfried Herold: Yeah. I mean, the fundamental problem really is that, I mean. It's not… it's not 100% solvable, just to be clear, because of lateness of votes, and because there's inherently some kind of, mini consensus protocol, but, I mean, you can sort of make it less exploitable.

Justin Florentine: Cool. Okay. Anybody else want to chime in on that one? It's an interesting one. Okay. Alright, we're getting, we're getting down to the end here, we only got 9 minutes left on time, so… One of the things that was an interesting point here was over-agnosticism of the lucid design, meaning that We don't… we do spec out, like, okay, here's a, you know, symmetric means of doing stuff with the Cha-Cha Poly stuff, but we don't necessarily commit to it, and we try to keep it kind of agnostic as far as, like, how the cryptography ever, how the cryptography works. One of the things that I was thinking was that

We keep the agnosticism, but we, constrain it. Meaning that… Yes, we allow basically anything. But we prescribe specific forms of symmetric encryption, and then add to it later on as we need to.

Gottfried Herold: What do you mean by symmetric encryption?

Justin Florentine: Sorry, not symmetric, the, the actual decryption mechanism, the cha-cha poly stuff, I think that was what we were referring to.

Gottfried Herold: Oh, yeah, the touch-up poly stuff, yeah, but the… oh, yeah, okay, so you want the… But the cha-Chauly stuff is kind of… not the… is not the problematic part, to start with.

Justin Florentine: Well, right, but I thought we were saying that we want to be a little bit more opinionated about, like, which… Algorithms that we allow for that.

Gottfried Herold: I mean, currently, we only allow cha-cha, some cha-cha poly.

Justin Florentine: Yes.

Gottfried Herold: I mean, okay, so a bit of a clarity. I mean, this Chacha poly algorithm has only… I mean, okay, so basically what you have, you have these kind of key revealers, right? But what these key revealers basically do is, or how you should think about it from a cryptographic point of view, is they actually reveal not the key bit, they reveal the full message. So there is no encryption going on in Lucid whatsoever.

Justin Florentine: You could use this as just a commit reveal scheme, yeah.

Gottfried Herold: Exactly, you can use this as a committed review scheme, and this structure poly thing is basically an optimization, a network optimization, because it allows you to sort of, send your ciphertext committed under the symmetry key up front, and then later you only have to use the Lucid mechanism for the actual decryption key. But as far as cryptography, for the interesting part of Lucid is concerned, basically, this decryption key is your message.

Justin Florentine: Yep.

Gottfried Herold: And it shouldn't think… you shouldn't think about it as a key, in a way. Yeah, and the agnosticism basically is just… the interesting part of the agnosticism is just… which mechanism do we have that ensures that this key or this message actually gets eventually released? And the fact that it's a cha-cha, whatever key, well, is not really, relevant for the agnosticism.

Justin Florentine: So how is it different than the optionality issue?

Gottfried Herold: I think what you mean by the optionality issue?

Justin Florentine: So, let me just… maybe I'm not… maybe I'm misremembering the talking point here. Over-agnosticism of the Lucid design. Can we keep it, but constrain it? So, the problem… the problem with… This being overly agnostic, was…

Gottfried Herold: the… Yeah, the problem is, in some sense, that you, can sort of self-decrypt, or self-release, or self-reveal. The problem with the agnosticism is, and this is what leads to optionality in a way, is that we do not prescribe a mechanism that, Make sure that the key gets revealed, or the message gets revealed, even if the original sender doesn't want it to.

Justin Florentine: I see.

Gottfried Herold: Nice. It's completely orthogonal to the cha-cha pulley, whatever.

Justin Florentine: Yes, I see what you're saying, right. And that's… that is the agnosticism, and that actually is… if we were less agnostic about it. We might have some mechanisms for reducing that optionality.

Gottfried Herold: Exactly, because you could sort of prescribe… you could basically prescribe that, yeah, you have to actually rather… you have to actually encrypt it towards some, I don't know, towards some, trusted execution environment, or to some threshold encryption committee, or whatever, that will, as long… That will eventually decrypt, whether you want it or not.

Justin Florentine: Got it. Okay, so that's a design theme that we should further entertain, I think.

Gottfried Herold: I mean… I mean, in a way, the point about Lucid was always that we do not have such a scheme, and so we do without, or we can do the best we can do without. The question that, sort of, I was raising in the criticism was just that, hey, and this is kind of the problem, and I really don't see much of a way around it, is can you take Lucid as is, maybe implement it, and get it on-chain, and then later change it If we eventually, have some kind of cryptography that would allow us to do without this optionality, and.

Justin Florentine: Yeah.

Gottfried Herold: Yeah. Sort of, is it upgradable to a future where we may have a good enough threshold encryption?

Justin Florentine: That's a great segue to the thing I wanted to talk about, which is because… and I think you're right here, I think, like. If threshold encryption gets good enough.

Gottfried Herold: Yes.

Justin Florentine: Then this is broken.

Gottfried Herold: What do you mean, broken?

Justin Florentine: Well, the, the, kind of, kind of… I shouldn't say broken. I think…

Gottfried Herold: It's superfluous.

Justin Florentine: Yes, yes.

Gottfried Herold: Supersede. It was superseded, in a way.

Justin Florentine: Yes, it would be a complete…

Gottfried Herold: better.

Justin Florentine: You could not plug it into… you could not plug it into Lucid, you would build a whole new design.

Gottfried Herold: Unfortunately.

Justin Florentine: Yeah.

Gottfried Herold: And I see very little way around this. One reason being that, depending on details of the threshold, I mean, there is various flavors of threshold encryption, with slightly different functionality, and depending on which one you use, you would use a different scheme, and we wouldn't… we cannot know at the moment if If we ever get one, which flavor it would be. And the… The, sort of, the maple design would basically have to account for that.

Justin Florentine: Okay, so we're guarding up on time here. The last bullet point that we had on here, let's just skip it, because I don't think we did any of this exploration. Did anybody explore using frame transactions and account abstraction for anonymous paymasters? I did not. I did not get to this.

Gottfried Herold: I know, I didn't know. I mean, I just… I brought it up, essentially, but in the blog post, but, yeah. I mean, I have no idea about it, just wanted to make people aware of that. This would be something that we would need, essentially.

Justin Florentine: Same here. So that'll get kicked down the road. Now… Threshold encryption. We keep talking about how Lucid exists because threshold encryption isn't ready yet. I am not a cryptographer, and is that a true statement, and is that a thing that I should be more open-minded about?

Gottfried Herold: I mean, it is essentially a true statement.

Andrei Lapets: I mean, it depends on who… it depends on who you ask, right? I mean, there's obviously threshold encryption is being used in production for, you know. tens of millions and hundreds of millions of dollars right now by, you know, I mean, defense, other wallet providers. I don't think that there… I think you can make the argument for other applications like this, there's no production deployment of threshold encryption, so that's the argument you would have to make if you want to make that argument.

Gottfried Herold: I mean, to be fair, also, you have to be aware that we have very unique, or very… we have, kind of, design constraints that other applications do not have, and there is a bit more… a bit more clear statement would be we have nothing that is good enough for our purpose. Which, includes, in particular, the problem that you want something that is post-quantum secure. This is a big, big, big issue, because almost all threshold encryption solutions that are… that exist right now in the literature are basically based on pair… pairings, which are not post-quantum secure, so any kind of… they are basically not future-safe. And among those, that are not, you have the other problem that there is usually a very high setup cost involved, oftentimes, or large keys, or much communication that scales with the committee size, or with… that is with the size of the people who sort of need to decrypt, or how often the decryption committee changes, and whatnot. So, if you have a kind of a small number of participants to it.

it would… it might even work, and that's the other question, is do you sort of decrypt every transaction individually? Do you decrypt them in bulk? There is a lot of things you can do. I mean, Benedict actually wrote some notes about, sort of, the requirement list. It's long, and we basically have nothing that fits our requirements. Other applications do have Other requirements, and the existing schemes might fit for them. But we do not, unfortunately.

Justin Florentine: Okay. Can I just keep asking that every week? Is it ready yet? Is it ready yet? Is it ready yet?

Gottfried Herold: I think if you had something, we would tell…

Justin Florentine: I mean, the crypto.

Gottfried Herold: team would basically tell you and actually design something.

Justin Florentine: Okay. is…

Gottfried Herold: We are monitoring this, not for Lucid, for one thing, and we are actually also working on things related to this question, and I mean, good enough threshold scheme would, in fact, be extremely useful for Ethereum, not just for encrypted members.

Justin Florentine: Yeah, yeah.

Gottfried Herold: There's other… parts of the protocol.

luis: Would it be good to have the list of all the requirements from the Lucid perspective, and then we can share that around with photographers?

Gottfried Herold: I mean, not from the Lucid, but from the encryptor, from the Ethereum perspective. Yes, I think Benedict has written down some, has… I can… let me just… I put the link into the Telegram chat, because we actually have such a thing.

luis: Great. Excellent.

Justin Florentine: And if anybody, needs help. connecting with anybody else, either me or Loring, would be happy to help facilitate that. We are at time. Thank you so much. This was great turnout today. I think we got a lot done. See you around the internet.

Mark Holt: Good.

Gottfried Herold: But, yeah.

luis: John?

Andrei Lapets: Yep.

Anthony: Thanks, everyone!

Mercy Boma Naps-Nkari: Bye.

Loring: Thanks, guys. Bye.

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