Encrypt the Mempool Call #3

Transcript

Jannik Luhn: Nope.

Justin Florentine: Yeah, Nick, what's up, buddy?

Jannik Luhn: Too much, how are you?

Justin Florentine: I'm doing alright.

Jannik Luhn: I can't see your RoboCop poster in the background anymore.

Justin Florentine: I moved my desk, yeah. Don't worry, though. Don't worry, here it is. It's over there.

Jannik Luhn: Nice.

Justin Florentine: Give folks a couple minutes to filter in. Hello, Gottfried.

Gottfried Herold: Hello!

Anthony: Hello, good morning, good afternoon, good evening.

Justin Florentine: Hi, Anthony.

Anthony: That was a good one.

Justin Florentine: Good. Hey, Anders!

Anthony: Hey, hey!

Justin Florentine: Alright, alright, alright.

Anthony: Finally in the same time zone as you guys.

Justin Florentine: Okay, this seems like enough people to at least get started. Hello, everyone. Welcome to Encrypted Mempool, call number 3.

Anthony: Mmm.

Justin Florentine: It's April 29th. We are being recorded. This will be posted on Forecast later on. There'll be, an AI transcription, likely, a summary, and all that fun stuff. We have a big agenda today, so this is fun. This is good to see. I know it's been a little… a minute since we last met, but let's get into it. Anthony, do you want to kick us off with, some of the things that you've been talking about? You have another series of calls. Would you like to plug that and kind of, inform everybody as to what it is?

Anthony: Yeah, absolutely. So, hey everyone, I'm Anthony with the Shutter team. So, been working on a number of different things, just trying to figure out other ways to help push, the Encrypted Mempool forward. So, we have this call, which is really focused on the technical aspect and development of Encrypted Mempool. And so we had this other thought that, you know, what about the aspect that focuses on partnerships and marcoms? and building relationships and doing outreach, so I feel like there was an aspect on that. So, what we did is we held, another meeting, just last week, held at the same time, Wednesday as well. And the main thing was to hold these meetings every other week, so alternating between this tech discussion, and having, like, a business MarComs discussion. So we had it last week, and we had a discussion broadly on what would be, what are some

challenges to go and encrypted… getting an Encrypted Mempool on Ethereum, and what are some of the priorities we should be looking at as well. And then we divided it into Marcoms, and then we divided it… not just MarComs, but business marcoms, and we did it into tech as well. And so I just wanted to share it with you guys, just to give a little bit of visibility on it, and for helping with the discussion today, and showing what's kind of… we're thinking for the other one. So, if you'll allow me, I'll just share my screen really.

Justin Florentine: Exactly, and then I'll just…

Anthony: Quickly go through it. Sorry, one moment.

Justin Florentine: Yep.

Anthony: I have a lot of things on my screen. Alright, one moment. Let me… Do one more thing…

Justin Florentine: Okay, we got your screen, buddy.

Anthony: Alright, sorry for that, guys. So anyways, we're doing a GitHub for each issue, for each, a new issue for each event, just to get an overview. So anyways…

Justin Florentine: Would you mind, real quick, just posting the link to that in the chat? I believe it'll get captured and put on forecast that way.

Anthony: Really? That's great. Thank you. One moment… .

Justin Florentine: Or you feel like I can do it.

Anthony: It's alright. I don't use Zoom very often, so… Actually, could you post it in there? I apologize.

Justin Florentine: Yep, yep. Okay.

Anthony: So, a few things with the discussion, just gonna go through a bunch of them, but very quickly. Everyone can look at it a little bit later, but some of the barriers we saw were concerns around execution quality, optimization, and reverted transactions. Core devs don't have enough time to review all proposals in depth. Unclear about whether wallets will want to adopt EMs, and users will want to use EMs. Concern about technical difficulties of implementing EMs. competition on private mempools, or offer potentially better incentives. Belief that there might be better solutions than EMs for fair ordering. Why should we do it now, when we could wait later, when there's other things that could come forth? Not enough hype around EMs, as with abstract, account abstractions, EIPs, how do we get better buy-in, and need a more clearly defined target audience and channels for outreach.

So just sharing, some… some of the barriers that we saw for EI inclusion. And so, some of the things that we saw for strategy, as an maybe some priorities we could look at moving forward for tech and business marcoms. For tech, which we can also discuss a little bit today, would be, about how can we improve the execution quality. I just put a few different things in there, such as block value optimization and avoid reverted transactions. How do we prove the effectiveness, as a priority? Focusing… so one of the things we could do, we could focus on live implementation, such as Primev. Which would be an out-of-protocol, implementation. Could do a model showing effectiveness, which we've already discussed this about doing an MEV simulator.

And see if maybe we can do something about more papers and research for other people to comment on. Other things also include implementing incentives into Encrypted Mempools. I know, Murat from, Premv has discussed about this previously, and then we also got some feedback and thoughts from, folks from WalletBeat that were talking about. easy off-the-shelf SDKs for AM wallets integration, and then from there, how can we integrate better incentives? So, just from some points for some ideas for discussion, maybe a little bit later today. I'm happy to go through the business MarCom stuff as well, but I know it's a little bit off-topic. Justin, would it be relevant for me to share as well?

Justin Florentine: You know, this is a good question. I don't know, I appreciate being aware of all of this stuff, but I think maybe further discussion makes more sense to have on that call, as opposed to here.

Anthony: Absolutely. So, Justin, you just shared this link in there, and I will share the link, to the next call for anyone who would want to join the Business Marcoms discussion as an option.

Justin Florentine: Great. Great, and I was unable to attend that one. I will try to make the next one.

Anthony: Okay, no worries.

Justin Florentine: Awesome. Thanks so much. Thank you. Great. Great, great, great. So, on to some of the more technical aspects of our agenda. One of the questions that had popped up that I wanted to discuss, and this might be a quick discussion, Anders, I don't know if you are prepared to speak to this, but a number of people have asked me how Lucid deals with, you know, we don't want to go to the bad old days where you had a priority gas auction for block space, and you kind of reintroduce a lot of the wild swings in gas prices. My answer to that has been, well, it's not all of the block. It's only part of the block.

Anders, is that a correct answer? Is it a sufficient answer? And do you have anything you'd like to add?

Anders Elowsson: Well, maybe I could say… well, concerning… so, we are talking about the functionality of a priority gas auction, where you bid with the priority fee, but what would happen here is that you would bid with the top-of-block fee. So used to, separate out these different effects, and then we burn this top-of-lock fee. Essentially, because we are ordering these, transactions based on the top-of-loc fee that they pay. And I assume that you would be hired to get first ordering there. And we use, inclusion lists to ensure that these transactions will get included. And then, what should we say more about this question? I haven't prepared anything, so it's hard to say, but, I mean, there's, like, one concern I've heard that I'm not, like.

in itself, not agreeing with fully. And that concern has been that, we would end up in a situation where transactions just revert. on Shane. And that this would then be, like, a big concern in itself, that we would waste a lot of block space, for example, for this. And the case is, of course, that we are not… You reserve a lot of block space. And then you revert. Okay, and we are not wasting the block space that you reserve in this case, because that block space can be used by the builder. We have a one-slot auction, and we have a two-slot version of Lucid, and in both of these versions. you reserve the full gas limit, but then if you revert, if you are one of these transactions that in the end, didn't want to execute, and if this is the concern we are talking about when we're talking about proprietary gas auction, then I would say that I wouldn't attach too much weight to it, because you can, as specified, use that

CAS that you reserved anyway, because you can just add other transactions then if they just revert to the And the builder will, of course, know that, because the builder will execute the top of block, the first thing it does. But there is one concern that it's a bit of a side… it's not, like, political auction concern by itself, but it's, like, the main concern that we have with Lucid, I would say, is the fact that In the AP, I specify two different things. I talk about exogenous map, which is the map that you try to extract based on what happens outside of Ethereum, and I talk about autogenous map. that is the map that you, as a transactor, this is, like, information that you provide to the chain. And what Lucid tries to do is to allow for autogenous map.

transactions without Autogenous map to execute without anyone else seeing them beforehand, before they are… before they are revealed. And this is the property that we want, but ich bilau. If we allow… if the outcome becomes that you only allow for extracting exogenous map, that is to say, you wait until you make the commitment, then you observe how the markets outside of Ethereum move, and then you only reveal the transactions that, that, in turn, actually were profitable, based on the commitments that you made, then we can say that, okay, then the Encrypted Mempool and the whole design does not provide that much welfare or, like, value to Ethereum. Because this is, this is, of course, not… not the main thing that we want to enable. We would burn, we would burn that, that, that map, in this case, because we are… we are burning the entire fee, but… but… but… but…

At the same time, we must concede here that, this would not be ideal. And the IP then sets up the equations for when this could happen and when it could not happen, and we have a top of block fee that you are returned, if you reveal, but if you do not reveal, you have to pay the whole fee, and you are returned, I think the settings now, it's 1 to 128, or something like this, or 1 to 256. So you're, you're returned, You are paying 1 to 128 for the rights to be at the top of the block, but if you do not reveal, then you'll pay $128 more. than otherwise. So this is a way to discourage these exogenous map extractors, and the other is that you are allowed to build these… I call it, like, decentralized block building, because you're not just providing one transaction, you can provide a bundle of transactions, and it's like a decentralized block, essentially, that you can provide.

And all of these transactions in this bundle, they share, the fee that they, they can use for ordering. So I guess that would summarize the… my position, yeah.

Justin Florentine: Thank you, Anders. It's interesting that you mentioned bundles. As we segue into… and it's Tomas, he's not on. We do have a bullet point on here to talk about encrypted frame transactions, and when you said bundles, that kind of made me think of the way that the, frame transactions allow multiple sender frames to be, you know, queued up and effectively bundled. there is a design here. I would love to talk to Thomas about it, but he is not on the call, so that's okay. We can put a pin in that and, circle back if he joins the call, or defer it to our next call.

Anders Elowsson: Maybe I should mention that there were some concerns I had with this encrypted frame transaction. We discussed it in the call, the last call also, but I brought up the concerns I have, these 8 bullet points that I answered on the EAT research post of encrypted frame transactions. which I think make this design as such, problematic. But, but, using frame transactions can be incorporated in various ways. I think it's reasonable. But with this specific design, I think that there are some reasonable concerns regarding, for example, we really want to have this reveal, Commit revealed part of the critical path. To enable skating for some… and there's many others.

Justin Florentine: How did you feel… one of the things that I liked about this approach, and I'd like to hear your thoughts on that, is the… the… The modifications that are required for EPBS. I like the idea of EPBS no longer committing to a state route, but committing to a transaction route. Was there anything problematic about that aspect?

Anders Elowsson: Can you explain what you mean?

Justin Florentine: Well, one of the things that Encrypted Frame Transactions introduces I feel is more powerful than even the frame transaction mechanism. And that is… Not requiring a state route. For builders, to commit to. Builders no longer have to actually execute things, they just have to commit to this order of transact… these transactions in this order will be in their, in their block. And so, they don't need to have a key, because they don't need to execute it. I found that very useful, and I don't necessarily understand why it would require frame transactions. And so, it might be one aspect of the design that we could actually use in Lucid.

Anders Elowsson: But if the builder is not executing the transaction, then they will not know the post state, then they cannot, for example, add transactions up to the gas limit, etc. We are wasting, because if you don't execute a transaction, you don't know which transactions will revert, you only have a gas limit, so you would waste a lot of block space in this regard.

Justin Florentine: Because you can't recover the ones that reverted. Interesting. Okay.

Murat Akdeniz: They also can't background the block, which, you know, block builders do.

Justin Florentine: You can't say that again, Murat?

Murat Akdeniz: Sorry, were you able to hear me?

Justin Florentine: Yeah, you're a little faint, but I can hear you.

Murat Akdeniz: Yeah, I was saying, you know, they… background the block, usually, right? So, they wouldn't be able to do that if they don't execute.

Justin Florentine: Oh, right, to queue up the next block.

Murat Akdeniz: No, to extract the math from the block, which, you know, they used to return fees and profit and all that.

Anders Elowsson: I'm not sure of the exact interpretation of not executing block. I don't remember. It was a long time… it was months ago, almost, I read that research post, but I… in point 3, in my comments on that research post, I discussed this specific thing with, Where you have, non-reveils would encroach on the available workspace, at least. So that's one aspect of it. Maybe another… I don't know if it was on the agenda, but I see Gottfried is here. He was… has been also talking about another… Are you ready, or do you want to talk about your thinkings of other stuff?

Gottfried Herold: I mean, there's… most of the things have been covered here already. You already said some of the things. I mean, yeah, I mean, from my side, I mean, there is some cryptographic and some kind of design questions. I've also been thinking about more of a I don't know, three-slot approach, because it sort of simplifies certain things, and, I mean, some kind of technical aspects, like, But this is not really… I think, I'm not sure whether this is meaningful to share this in this group, or I've thought more things about more in this detail, but one of the things I've been thinking about was whether we need encryptions at all, because in some sense, you can actually get away with

Mostly commitments, in a sense. at the expense that you might need to have something like, more interaction or something like that. But, I mean, it doesn't change the, the overall concerns that, I mean, I have with Lucid, with the proposal, at least. Mostly was… which is mostly about, sort of, the option… the optionality of non-reveal and the ensuing economic, sort of, problems that we all are aware of, anyway. I mean, there are some optimizations you can do that sort of make things a bit more efficient, or a bit more, sort of, more secure. Like, hey, you actually only commit to things, and yeah… You basically commit to your… to your ciphertext beforehand, and you don't care about how it sort of goes on block, and so on, and yeah, sort of changing sort of this whole bundle mechanism, or the fact that you… in some sense, the fact that you, have to post the encrypted data beforehand, so that you have sort of a short,

A short path on the… sort of only a short key on the critical path. is sort of nice, but I would prefer to keep sort of this outside of the Lucid sort of design, and move it more on a… make it more of a network optimization that's sort of orthogonal to the design of Lucid. By basically commitments, and then say, hey, actually. And this is one way of realizing it over the networks to make things a bit more efficient, but not make it mandatory from the ERP point of view. This is just something we can work on. Okay. I'm making sense here.

Justin Florentine: No, you are. In fact, you're kind of, I think I'm thinking in a similar direction as you lately, actually. I don't know if I want to get into it in this meeting, but maybe I'll follow up with you later on.

Gottfried Herold: Goodbye.

Justin Florentine: Yeah. Cool. I did want… I'm glad to see you here. I did put, some time on the agenda for, discussion of the same-slot decryption for Lucid Post. That you published. I personally haven't had a ton of time to go over this. Is there anything you'd like to, bring up for discussion?

Murat Akdeniz: Yeah, and thanks for kind of carving out time for this, and just to follow up on that point, you know, we operate a production commitment network for block builders on mainnet. And the area that commitments fall short on is censorship resistance, right? So, when you send even a profitable, good transaction to a major block builder. They're able to say, well, you know what, I have this, you know, handshake deal with this other sender that I pay them, you know, a million dollars for a year, so I'm just gonna put their transaction instead, right? So, I think that kind of, censorship is ultimately what encryptions allow us to, kind of avoid. But, you know, to tie this into the same slot, the encryption.

You know, the three points that that post tries to make is, one, this kind of execution optimization, obviously, right? So if I have an encrypted bundle and you have an encrypted bundle. and they both go on, and they're both going after the same opportunity, I mean, it's gonna waste a bunch of block space, one of us is gonna get reverted, etc, etc, right? So, and then, you know, there's ordering-related optimizations and other things that same slot decryption. But beyond that, it also, you know, my proposal at least introduces, this kind of keeper payment, that block builders pay, in order to get this, you know, better block, essentially, right? By knowing this information. So I think these two points are some of the meat of it. And then, you know, the nature of it is happening also, outside of protocol, so that allows, you know, us to cleanly reduce slot times, etc.

You know, some of the details you can access in the post, but, these are some of the main points, that, you know, I brought up, and, you know, I'd also like to thank Anders for, you know, replying it. And I think we seem to be aligned on, you know, what this brings forward. So yeah, excited to kind of have a greater discussion on this.

Justin Florentine: Grant. Thanks, Murat. Anybody have anything to add?

Murat Akdeniz: I guess one, open question is whether we would allow this, slot end optionality within, Lucid to allow for this, and I guess it's implied that, for a line, that would be the case, but I want to make it explicit. That means, like, we're… A block pillar can include, the, the encrypted transactions in, slot N or N plus 1, Granted, they have the key, obviously, for…

Anders Elowsson: Yeah, and so while this would perhaps be a little bit more burdensome to implement, I think it's pretty reasonable for various different reasons. To allow, a, a, for example, you have the key, key publisher may have, for example, a lot of, transactions that it was gonna include in a bundle. But then it turns out that it may actually want to include some of these transactions in, as just plain text. And under such… because it may be, for example, the builder itself, and under such circumstances, it's… could be reasonable to do so, to have, To have, like, seal transactions with a key act, to some extent as a plain text transaction.

Justin Florentine: Yeah, so are you saying that Key Reveal now is covered by consensus, and we would actually be able to say, You might not have had the key, but you should have had the key, and so you must include this at N plus 1?

Anders Elowsson: No, it's… it's like a… it's like a way to… to increase, the, the, the amount of… the optionality of some… of the key publishers. If the key publisher… this was previously called the decryptor. If the key publisher holds the… The seal transaction, and it has also received the key, which has been decrypted by the key publisher. Then, if it is the key publisher that builds the block, block or has some trusted relationship that the transactor, in turn, has deemed that it would like the key publisher to use, then it would be possible to allow the sealed transaction coupled with the key. Put together and act more or like a normal, regular, plain text transaction. And so it could go directly in… inside as a plaintext.

Justin Florentine: Huh.

Anders Elowsson: There is some complications doing that, I think, but it's like, it's like a reasonable thing that at least can be considered.

Justin Florentine: This is interesting. Okay.

Murat Akdeniz: Yeah, I think that solves the execution quality issue.

Justin Florentine: But, can you explain maybe a little bit more how? Because to me, it sounds like in that case, it's deferred to slot N plus 1, and so you're still getting stale prices. Like, how does that preserve execution quality?

Murat Akdeniz: My understanding is that it would not be deferred to plus one, right?

Justin Florentine: Okay.

Murat Akdeniz: you have the plain text, so you could include it in N. And, you know, you're able to optimize it because you're able to see it.

Justin Florentine: And so, it's only the case that Key Reveal was not timely, that you would get N plus 1 prices.

Murat Akdeniz: Right, or if the, you know, the sender did not opt into this.

Justin Florentine: Sure.

Murat Akdeniz: you know, I'm okay, but then plus one or whatever, right? So, yeah.

Anders Elowsson: I would say that… there is not even a key reveal in this case. We couldn't call anything a key reveal. You can just treat it as, essentially, a plain text transaction, but in a different format. And if the key is not supplied in this format together with the sealed transaction, then this transaction is not valid. It's trying to act like a pintext, and it has to have a correct key for it.

Gottfried Herold: I mean…

Anders Elowsson: We'll have to pay more for that.

Gottfried Herold: I mean, like I said, I mean, before, I mean, I think we should basically just do commitments anyway, and just view these keys as a kind of way to sort of remove, sort of latency or data from the hot path. So basically, your transaction ticket would just have a commitment, hey, which basically means you have to have some kind of committed, well, ticket, which basically says, either in this block or in the next one, the builder is enforced to include a transaction that has this hash. And basically, the key and key reveal is just a way to enforce this, essentially, with low latency on the hot path. So there is not even a key, necessarily.

Murat Akdeniz: But the builder needs to…

Anders Elowsson: Nicely with that designer. But, but, Yeah, but the issue is, perhaps, yeah, we… Problem, maybe, is… the reason for using keys is that you can have a very… you can have a very short propagation window for a key, whereas if you have a…

Gottfried Herold: I don't say we should not have keys, it's just that keys are optional, basically. Make the keys, basically, as a transport mechanism completely optional.

Justin Florentine: As opposed to, like, a commit reveal scheme, where it's just the hash goes out, and then…

Gottfried Herold: You have a commit reveal scheme, and basically, and basically, in part of the commit, basically, just a hash goes out, I mean, it's a bit more complicated than because… because it's just not just a hash, because.

Justin Florentine: Right, right.

Gottfried Herold: But at least we're hiding. Usually, when we think about commitment in the Ethereum context, we only look at binding property. Here, we actually also need a hiding property, so you have to be a bit more careful on the topographic side, but yes. And then, of course, you can say, hey, actually, I have this commitment, and by the way, here's some extra data associated to it, which is basically some blob data that basically is the committed transaction, and here is a hash of the key, and then Lucid basically says. And if, sort of, this mechanism, sort of. sort of, if sort of… if, sort of, the timeliness Committee attests to the availability of this data, then the next proposal basically has to reveal it. But from the consensus rules.

Other than that, if this transaction with an appropriate hash ends up on the chain, we don't care where it came from.

Justin Florentine: Do you think that's possible while… Do you think that's possible without leaking metadata and still being able to give the builder what they need to know? So, for instance, gas, right? Like, how much gas is going to be used for the.

Gottfried Herold: That's part of the ticket. That's part of the ticket, of course.

Justin Florentine: Right.

Gottfried Herold: But that's already the case now.

Justin Florentine: Okay.

Anders Elowsson: Yeah, maybe you should write up a little bit more details about this microscope.

Gottfried Herold: Yeah, I mean, I just did not have time. I had a lot of other things that basically went on my plate in the last month, but that's something I wanted to discuss.

Justin Florentine: I mean, it's kind of reminded me of the sealed transactions design that we went over back in Berlin, Anders. Like, I want to make sure that we're not… Retrodding that ground.

Gottfried Herold: I mean, it is basically a sealed transaction, it's just…

Anders Elowsson: Similar, yeah.

Gottfried Herold: this, it's just that, sort of, you use, sort of, still an encryption mechanism as a transport mechanism, but it's not, sort of, locking in the encryption mechanism, because it allows in certain… because there are use cases where this encryption mechanism is completely unnecessary.

Justin Florentine: Yeah.

Gottfried Herold: And it sort of just… it just incurs costs, which we don't need to pay if you don't need it.

Murat Akdeniz: I'm a bit unclear whether this allows The censorship resistance property, though.

Gottfried Herold: How is the censorship resistance property related to this question?

Murat Akdeniz: Maybe the particular use case, is better to kind of highlight, right? So, I have a transaction, it's a good transaction, it should go in this block, but the block builder has a handshake agreement with his friend. And therefore, my transaction always gets censored due to this, right? So are we able to kind of break that.

Justin Florentine: Quick.

Murat Akdeniz: this, approach.

Gottfried Herold: I mean, it makes no difference, it makes absolutely no difference. I mean, you can still sort of prevent, I mean, if you sort of allow either same slot or next slot, then, of course, sort of a sensor in builder can delay to the next slot. I mean, similar to what fossil does, I mean, fossil… even the fossil design, which this is basically all of these constructions are heavily leaning onto, do not really prevent delaying transaction inclusion. It just makes it sort of… it just sort of limits it. Which is probably good enough.

Murat Akdeniz: But if they commit to it when it's encrypted for this block number, then they cannot delay.

Gottfried Herold: It's already sticking.

Murat Akdeniz: If they commit to it while it's encrypted to a certain block number, then they cannot delay.

Gottfried Herold: Yes, I mean, they… I mean… so, okay, so maybe a bit of confusion. Basically, if you say, yeah, I commit to, sort of, the block content, and sort of the… I mean, something like Lucid, basically, I mean, if you have Lucid with some optional, sort of, same-slot decryption, or same-slot revealed rather than… decryption, as I say decryption, then basically this means that it can only be delayed, sort of, into the next block, essentially.

Murat Akdeniz: Yeah, but, you know, whether the block info is in the protocol or not is less of my concern, but The, the… like, we wanna have… And that commitment includes… sure, it's out of protocol, but it includes the block number. So they don't have the… the only optionality they have is whether to commit or not, because they can see the transaction. Right? But once they're not able to see the transaction, then they don't have that kind of delay option either with this type of commitment. So, that's particularly the type of censorship resistance We're looking for so that, you know, getting the opportunity, the map of opportunity, top of block opportunity is a permissionless scheme, and you don't need this handshake agreement with the block builder and pay them a million dollars every year.

Gottfried Herold: I don't get what you mean, sorry.

Justin Florentine: I'm also missing the idea of committing to the block number, I think.

Gottfried Herold: So why do you have to commit to the block number in the first place?

Justin Florentine: And you were breaking up a little bit, Murat, like, in the middle of your explanation, which could contribute to some of the confusion.

Murat Akdeniz: Yeah, I'm sorry about that, baby. But yeah, this kind of, friendship priority, I guess, property is what we're particularly looking to break with encryption.

Justin Florentine: So that's a good question. I want to think about that a little bit harder. intuitively, I think you're correct, but I want to make sure we draw clear lines between what is Fossil's responsibility and what is… Lucid's responsibility, right? And so in your hypothetical, are you, basing censor… you're basing censorship on the transaction content, not the transaction sender, right?

Murat Akdeniz: That's right.

Justin Florentine: Right. I'm gonna put this down as a discussion point. Lines between fossil and lucid. Because we think of EPBS, Lucid, and Fossil as sort of like a holy trinity that all kind of have to work together for censorship resistance. And that can both be true, and also… Harmful, because it, you know, kind of obscures Design responsibilities, right? So maybe that's a thing we should think about and do some writing on. Okay.

What do you need next, for this same slot description? It sounds like we need to read it a little bit harder, it sounds like we're not quite grocing it. Well, maybe Anders probably grocks it a little bit better than I do. And so maybe that's what I need to do, is just catch up to him. But this, this is specifically, Murat, you see this as an extension slash modification to the Lucid design, right? Once it has adopted the same slot. Stuff, right?

Murat Akdeniz: It would have allowed two things. One is the, you know, it's okay for the builder to include it in slot N, and they are a little addicted or whatnot. And I think there's, like, a decryptor key field, or something like that. But, that is able to basically assign…

Gottfried Herold: Brad, your audio is, not really working.

Justin Florentine: Okay. Alright, well, we'll, we'll circle back, might be having some technical issues here. Thank you for that. Feel free to jump in if your audio recovers. We still have 20 minutes left, so I did want to, maybe kick around a couple of more things from the agenda here. Okay. Marat's gonna start keeping up with the chat. Alright, so, fantastic. Way to adapt. Are there any updates to the 8184? the specific Lucid EAP. Anything that needs to be brought to anybody's attention. I didn't see any PR.

Anders Elowsson: Absolutely.

Justin Florentine: lately.

Anders Elowsson: No, I made my last updates maybe 3 weeks ago, to… the last update was for the marine welfare section. That is, like, the biggest one in the rational that explains how it works and what works and what does not work.

Justin Florentine: Great. Great. Okay, thank you, Anders. Another interesting, point brought up by Data Always, actually, and there's a link to the tweet, but it's essentially findings that sandwiches, can be pretty wide and really hard to spot. So I just wanted to bring this to people's attention. This is a good example of… how we don't know what we don't know, right? Like, the dark forest is dark, and there are many… there are many aspects of MEV that could be going on that we don't understand, and that's why I'm a big proponent of encrypted mempools as a solution for them, because it likely covers a lot of things that we don't quite Know is going on. So I don't know if anybody had a chance to read this, to take a look at the analysis,

Any thoughts on this, as far as, you know, MEV is concerned? This is one of those situations where I'd love to have, builders on the call, or, you know, crypto economists, etc. But the TLDR is that, like. They're seeing some pretty wide sandwiches. That are only now being detectable.

Murat Akdeniz: I think Lucid makes them riskier. And I think that's the only lever we have against these wide sandwiches to… Make them riskier to go for or apply. So I think it's a positive development in that sense. But I think generally, like, this kind of notion is unavoidable and a censorship-resistant… You know, system where, you know, somebody can just send whatever transaction they want.

Justin Florentine: Yep. Yeah, you're never gonna be able to prevent the front of the sandwich, because spam will always be a thing. Right? And with infinite width possible, The back of the sandwich is also unavoidable.

Gottfried Herold: I mean, sure, I mean, in principle, if you had some… I mean, the problem, I mean, ultimately stems from the fact that you're in the point of information reveal about your intention reveal and intention execution happen at different times. I mean, that's basically the ultimate reason.

Justin Florentine: Oh, that's an interesting perspective, okay.

Gottfried Herold: Just remember. Yeah. But basically, you reveal… basically, the problem is that the intentions… you're revealing your intent and executing your intent do not happen at home equality. That's basically the reason. Yeah. I mean… basically, if you had some kind of Encrypted Mempool design that's guaranteed, without all this… without… without all of these optionality things, for which we do not have the crypto, unfortunately, we're working on it, but we don't have it, then, I mean, you could have that in some sense.

Justin Florentine: You mean, like, an FHE design, right?

Gottfried Herold: Like an FHG, I mean, even, let's say, some verifiable delay function, let's say something that basically guarantees you, basically have a guaranteed decline. There is no optionality. You basically get rid of the optionality, you have an enshrined threshold decryption, enshrined VDF with delay function stuff. maybe even some trusted third party that is basically just, trusted execution environment, something like that. None of… none of this works right now for various reasons, but if you had this thing, you would basically have the… the reveal, your intention reveal, apart from maybe some metadata about it, but even that you can sort of hide, and the execution sort of atomic. And that's, in some sense, the reason for for it.

At least for sandwich prompt running. So, I'm not… I wouldn't say it's unavoidable.

Justin Florentine: Right.

Murat Akdeniz: But that's the general sandwich, right? Not the wide sandwich.

Gottfried Herold: What is the wild sandwich, then?

Murat Akdeniz: I mean, the white sandwich is essentially price manipulation, right? Like, before you even send a swap or something, I'm, like, you know, shorting this coin, because I'm a whale, and I think, you know, I'm gonna just short this coin. And I short it. So by the time you make a swap, whether it's, you know, your intent is revealed or not, the price you're looking at is actually, you know, my manipulated price, right? So then you execute within that price. And then I clear the market after, you know, a whole bunch of these execute, and get the price back to what it was, basically.

Gottfried Herold: It's true, but it's the same, sort of the same principle, that whoever manipulated a market knew about my intent to trade beforehand, before it was executed, otherwise I couldn't do this.

Murat Akdeniz: No, they do it. It's blind, right? So they can do it blind, because… I mean, they have the monetary advantage, right? Like, let's say I have 20% of the supply of this coin, so I'm just gonna dump it for the next, you know, 10 minutes. So you don't have the option to get a better price at this point, right? And then I'm gonna, you know, sweep it after the 10 minutes. So, all of your… All of the trades that executed during this 10 minutes. executed at the price that I manipulated it into.

Justin Florentine: I think that's true, and I think I'm gonna take a homework assignment to come up with an alternate term, because sandwich is dope. It's got really good marketing, but it means a really specific thing. And what we're talking about is not really a sandwich, because we're not targeting anything, right? A wide sandwich is…

Gottfried Herold: That's just price manipulation, that's just…

Justin Florentine: It's rushing the buffet, right?

Murat Akdeniz: You're gonna screw it.

Justin Florentine: bring everybody in the restaurant, not just the one-person sandwiches. I don't know, I'm gonna workshop it, but it's an important distinction, and I think…

Gottfried Herold: Yeah, it's just general price manipulation that has nothing to do with, sort of, multiple encryption or anything.

Justin Florentine: It's like a… it's like a high-frequency trader thing, more than… more than a targeted sandwich.

Jannik Luhn: Yeah, I'm not struggling.

Murat Akdeniz: great risk, so, you know, we can make that riskier, I think, and that's a good lever to pull.

Jannik Luhn: So, for me.

Justin Florentine: I think…

Jannik Luhn: you think it…

Justin Florentine: How do you think it gets more risky? Because in a world where encrypted mempools are available, there's less, in-flight market knowledge floating about?

Murat Akdeniz: Yeah, I would say so, that's probably the main thing, and then, even, like, the… any delay or… yeah, any delay on the information is even… like, is my strategy working within this 10 minutes, right? Because as soon as I open this, you know, manipulate the market, largely position, I'm listening to the market very, very closely to see if, like, it's working, or I'm in the profit, or I'm losing money, right? And I'm gonna close the position immediately if I'm, like, going in the wrong direction, because I took a huge risk. So, the less information that we can give during that time. And you have to wait the whole 10 minutes to see whether you're screwed or not is gonna disincentivize these people to kind of, open these types of positions.

Justin Florentine: And you lose the granularity of the mempool, right? In a perfect world where the mempool's fully encrypted, you really only have blocks to go on to inform that.

Murat Akdeniz: Yep.

Gottfried Herold: In particular, only somebody else could background the stuff, so…

Murat Akdeniz: True.

Justin Florentine: Okay. Fun, interesting. Okay, we've got 10 minutes left, want to keep things moving here. Strategic Priority Review. So now that we've had some discussions on designs that are in flight, lace news, etc, etc, I'm curious as to what we think changes about… our strategy. And our strategy is to mitigate toxic MEV in an upcoming hard fork, right? Like, that's kind of the vision statement that we're getting at here. We're probably looking at I-Star, right? what are our priorities to get to the point that when I start ships, You can't frontrun stuff. I'm being… I'm being intentionally pithy and succinct, in how I describe the vision statement. So what do folks see as the priority? I know in the past, I have thought that…

for both technical and marketing reasons, being able to visualize sandwiches and the way that an encrypted mempool can mitigate them would be powerful. Do we still think that's the case? Do we have alternate suggestions that things should be a higher priority? The floor is yours.

Gottfried Herold: You mean for I-Star on its own, or… Or for us.

Justin Florentine: Just for, just for Encrypting the Mempool.

Gottfried Herold: You mean as a selling point?

Justin Florentine: No, I mean, it's like, what do we think is, you know, the… the…

Gottfried Herold: The goal, basically, of sort of what is the ultimate goal?

Justin Florentine: No, I think we're clear on that. I think it's like, what do we do next? Like, what do we do… what do we need the most time to do? What do we… what do we need, you know, to invest in? Like, where do we get our biggest bang for our buck? Is it… is it prototyping? Is it visualizing? Is it marketing? Is it getting adoption from builders? Like… Open to ideas here.

Murat Akdeniz: I think a testnet version, makes it very tangible and real for everybody. And takes it from, kind of, the research phase to, oh, damn, this is, like, happening phase for a lot of the ecosystem.

Justin Florentine: Okay. Testnet. Oh, damn, this is happening. Ron Paul, it's happening meme.

Jannik Luhn: I think, ultimately, it's going to be the core developers who are going to make the decision on this, eventually. So, maybe it's a good idea to come up with a bunch of ideas what we can do. Testnet could be one, maybe cleaner specs or broader specs could be one. And then just ask them what they think… what would convince them the most.

Justin Florentine: So, testnets is a big one, so that's good too. Testnets will work towards that goal as well, Yannick, is what I'm trying to say.

Jannik Luhn: Yeah.

Justin Florentine: Right.

Murat Akdeniz: I like that, like, having a Lucid core dev session, or something similar, whether it's async or synchronous.

Justin Florentine: Okay. Do we think the, execution quality issue is likely handled by some of the same slot designs that we, discussed today? And is that an area that we need to maybe reassure people that, it solves?

Murat Akdeniz: I believe so, but, maybe we can… You know, formalize it a little bit, or, like, trying to… maybe that's the wrong word, but… you know, have… have concretely what it is in the EIP or some official, document, rather than, you know, just some disparate discussions and notes and youth research posts. Happy to work on that as well.

Gottfried Herold: Yeah, well, to be fair, I mean, maybe a bit of a pushback on this, sorry to be a bit of a party pooper here, but I'm not sure whether, sort of, the… some kind of these designs will, sort of, fly with core developers, or with, sort of, other, sort of, protocol upgrades, mostly because of the push, at least for the next hard forks, to basically shorten slot times. And I think there will be a lot of concerns about this.

Justin Florentine: And so a same-slot design exacerbates that.

Gottfried Herold: Yes.

Murat Akdeniz: So if you read my post, I addressed this with a tweak, right, so that you can… because the window is basically, not within the protocol to, do same-slot decryption key send. It completely abstracts it from the slot time, so you can literally have a 500 millisecond slot time, and it would still work.

Gottfried Herold: I have to check.

Justin Florentine: I'm gonna need to study that so I believe it. That's a great argument that we're gonna get beat up, beat up on. Not to say that your design doesn't work, but I just gotta be able to sell it, right?

Murat Akdeniz: Yeah, yeah, totally.

Anders Elowsson: Maybe I can clarify. So, essentially what this design does is, if we do it the way I would think that it should be done, if it is done, is that you move, essentially, the whole scheme out of protocol. And you essentially allow, Than the builder to, If someone would like to publish their key to a select builder, they can do so, and they can have some sort of auction. If we move this out of protocol, then I think it's more or less fine to do so. To have the builder commit to including a sealed transaction, just as any other transaction, as we were talking about, as essentially acting as a plain text. But paying for any extra burden that it has imposed in its…

While making its way into the protocol. So, what… the way it can be done is essentially that you… You're just turning it into a plaintext, but it happens off protocol, and the only thing the protocol sees different is that some of the transactions that turn up or seal transactions with an added encryption key, or if we follow what we have been discussing here with Kotrid, some commit revealed in another fashion.

Gottfried Herold: Yep.

Justin Florentine: Is it appropriate to open a PR into Lucid? To accommodate that?

Anders Elowsson: I'm… We can discuss the… yeah, to accommodate the… we can look at the complexity of it. To, to, to have, This was… I think it was even brought up in the re… no, maybe it wasn't, but it was sort of considered initially to have… to have the bill be able to provide the key together with… with the seal transaction, and it's… it's a reasonable thing to do, I would say, for… for various reasons, and for these things that… That is proposed here, and what's proposed here, is one of these reasons. So we can look at… What it would look like.

Justin Florentine: Yeah, I agree with that, I'm just having a hard time seeing the design, myself, so maybe it's not a… Maybe it's not a PR into the… EIP yet.

Anders Elowsson: Okay.

Murat Akdeniz: I can create, like, a landing page that kind of visualizes the concept so that we can evangelize better across the community, how, you know, this latest improvement is, and all of that.

Justin Florentine: Yeah, I'm just looking at the post here. Yeah, pictures are… really are worth a thousand words. Yeah, that's a… I think that's a good idea, Murat. Maybe… if you look at the, tomas's… encrypted frame transactions, he kind of repurposes a lot of the iconography from the original Lucid design. So maybe if we did something similar for this, that would be helpful. Cool.

Murat Akdeniz: Do you have the link for that?

Justin Florentine: Yes. It's listed on the… Agenda, but there's a fresh one right there in chat.

Murat Akdeniz: Alright, thank you.

Justin Florentine: Okay.

Gottfried Herold: That's where another sort of action item is mostly just for me, but just to inform you. I mean, we are trying to basically red-pill some crypto research just to look into, threshold decryption, or… To explain to them our needs a bit better, so maybe we get better solutions eventually from the broader cryptographic community, because that would really help, sort of, estuge all of these kind of concerns about optionality.

Justin Florentine: That would be a big boon to protocol designers everywhere.

Gottfried Herold: We have Eurocripts next… in the next two weeks, so we'll try to hold some workshops there and sort of do that.

Justin Florentine: Awesome. Awesome. Okay, and we're just at about time. We do have one last bullet point. Client team participation, who's missing? who's missing from these calls, and who can go get them, and bring them in. Thoughts?

Anthony: So, I have a little bit of a spreadsheet. We can just go through the clients and just check off who's here and who's missing. But, I think we just need to… I guess. Start identifying this so we can start moving forward.

Justin Florentine: So, when you refer to client team participation, I think it's way too early to actually start bringing in, like, all client teams. I think we need a CL dev and a EL dev, and I'm willing to be one of the EL devs, to do this, because… We need to… we need to… Prototype. Oh, I see you're… okay, you're thinking more along the lines of…

Anthony: And it could be other people as well, but I think if we're… there's a few things. One is development, and actually putting together a very strong Encrypted Mempool that we can use, but also, at the end of the day, if we wanted to get it pushed in the I-Star, we need to get other… we need to get client representation to these meetings, we need to get them involved, answer their questions, concerns, have them part of the process, so I think that would be good as well. I just put together a quick list, but it's probably missing some stuff as well.

Justin Florentine: Okay, great. Yes, I see what you're asking for, and this is a more intangible support than I was imagining. Great. Okay, Well, you can put my name down as the representative for Besu. And I can think of some… I don't want to name names in public, but I can think of some people that I might want to, reach out to on… on some of these teams.

Anthony: Absolutely. We can definitely take it offline, but, yeah, I'm hoping we can just get in more, people into the discussion, more representation, that way we can help move it forward. Cool.

Justin Florentine: Recruiting. This is really a recruiting problem. Awesome. Alright, and we're over time, but thank you, everybody. Super, super productive call. I know it was a big agenda, and we got everything sorted. Recording will get posted to forecasts, AI Summary will get forwarded to Forecast. I'll open, the next meeting agenda item, and try to pull in some action items. See you on the Telegram groups. Hopefully everybody knows where to find each other. Great work, everyone.

Gottfried Herold: Yeah, can you put the link to the other meeting or the Telegram chat? If you didn't do that…

Justin Florentine: Oh, yes. Yes. I agree. Thanks, everyone!

Gottfried Herold: Thanks.

Anthony: y'all.

Murat Akdeniz: See you guys.

Jannik Luhn: Nope.

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