Encrypt the Mempool Call #2

Transcript

Justin Florentine: V? How did you guys get in?

Luis: What?

Anthony: We're stuck in.

Gottfried Herold: Hello.

Anthony: Hello?

Justin Florentine: So I guess when you leave a meeting and transfer being the host to somebody else… That's not good enough. Great stuff, Sam.

Anthony: We got it sorted.

Justin Florentine: Sure. Hi, everybody. Welcome to Encrypted Mempool Working Group. It normally starts 10 minutes ago. So let's jump… jump into things here. I think folks are gonna start trickling in. I'm gonna go send a message real quick to… To let people know. We don't have a ton on the… well, we do have a ton on the agenda, look at this, new stuff's coming in. Great, great, great, great. Alright… Unbelievable. Every time. And just tell people what's up now…

Alright, so is folks here, good stuff. Okay. So, encrypt in the mempool! This is fun. Okay, we've got our EIP number for the Lucid design. That's cool, 8184. Good stuff. Good stuff. New additions to the agenda… wow, okay. Improved back running efficiency. Let's see, how do we want to organize all this? And maybe we should talk about some design, questions up front with regard to…

On-chain versus off-chain implementations, trust performance implications, that's a good one. Back running efficiency, let's see… Luis, are these your suggestions?

Luis: Yep.

Justin Florentine: I think that… Anders, welcome. So I think I wanted to… there's, there's 3 things that I wanted to cover, specifically, observability. Right? A demonstrator stack, And then… I wanted to talk about… hey, Anders, I wanted to talk about, So I spoke's recently dropped proposal for encrypted frame transactions. It's literally just got published. I don't know. 20 minutes ago, half hour ago. So, I guess, I guess let's start with the top, from the top. A demonstrator in observability. If we put the notion of… encrypting the mempool and the design for encrypting the mempool to the side. What would we want to build? To demonstrate the lack of an encrypted mempool.

And what would we want to build as kind of a minimal network stack that demonstrated maybe sandwiching, right? And how to observe it, and how to observe that it disappears once, an encrypted mempool design goes live. I think that's a good bucket of work that we need to get done kind of up front. So that can be the thing that we test against, iterate against, and… and evolve. So, Any thoughts on that, as far as what work needs to be done for it? How would you… how would you go about doing it?

Luis: two things come up to… come to my mind is one thing that Yannick, our colleague Yannick, has done in the past is, simulated that, just very basically, like, just simulated a simple AMM model, and then, kind of, with observability and with… or with encrypted and without encrypted. Transactions, and just kind of, like. But that's just a… just a model, it's not really a simulation, it's really just a model, I'd say, where I can share the link. And the other thing that we could use more practically would be, yeah, the Gnosis chain, the encrypted mempool on Gnosis chain. Because, kind of, like, in principle, that is an out-of-protocol implementation of an encrypted memo, right? In theory, we could…

Kind of like… Showcase what happens if you send a Something we've been thinking about in the past is just running a… Generic frontrunning… Frontrunner… But on Gnosis chain, and front-running all transactions that don't go through the encrypted mempool. So, but yeah, just high level, I think the Gnosis chain implementation could be used.

Justin Florentine: So, I'm curious, before we started talking about Gnosis, you were saying, you know. that there was a way to kind of simulate this. Could you elaborate a little bit more on that? Like, because ideally we would have something that would be easy to run local versus a Kurtosis stack, and you could kind of look at it and see, like, oh, here go a bunch of transactions, and you see them getting sandwiched. And then it hits the certain block height, and it activates it, and now the searchers are all sad because they can't find any sandwiches.

Luis: Yeah, I think this would… Yeah, what Yannick built in the past was one step… a precursor to that, I would say. It's more like this very simple model of an AMM, and then kind of, like. Monte Carlo-wise, simulated transactions, and different ordering, different ways to order, and, like. Also this, like, the topic of… How efficient is back running, per transaction backrunning, or per block back running? But I can… I could share… I could share the link. But I think maybe it's a precursor to what you're thinking.

Justin Florentine: Interesting. Stefan, you have a note here in chat. Would you care to elaborate? Yes, depending on the timing, we could consider building on top of that. A builder for EPBS. Okay.

Stefan Starflinger: Yeah. So… In general, we need just a sequence of transaction, from an AMM, And you just buy, some token, and then you sandwich this transaction by first buying it cheaper, selling it more expensive, and then just back running again. And we just need a builder for that, either, like, simulating is a good approach. But if we have a builder through EPBS anyways. We could consider using that. That's just an idea.

Justin Florentine: Okay, Luis, can you, maybe take an action item to talk to Yannick and see if what he's got It's been published anywhere? If there's a repo for it, we can take a look at it and try to run that.

Luis: Yep.

Justin Florentine: And then… maybe see how the builder fits into it for Stefan's suggestion.

Luis: Yep.

Justin Florentine: Does it have… I mean, the other thing that I'm asking from a marketing perspective is… it'd be nice to have, like, a little front end that you could tell a quick story, kind of an elevator pitch, right? So people could actually see the sandwiches and see them, you know, stopping. So I think, I think visualization is an important aspect to this that we want to make sure that we cover.

Luis: Yep.

Anthony: Yeah, I think that's definitely something we could do.

Justin Florentine: Okay Cool. Is the AI taking notes? It is being transcribed, hooray! Great, I don't have to actually take notes. This is… this is the… this is the future that we were promised. Okay. Cool. Now, that was one of the things that I really cared about. Luis, you had quite a few, bullet points here that we wanted to talk about with regard to… I think defining some of the efficiencies in economics, would you care to elaborate on… The need to improve… To better define the backgrounding efficiency.

Luis: Yeah, so this is triggered by, I think Data Always from… from Flashbars, right, who said… who made this point that… The… in the current private mempool, landscape, PBS kind of model, usually what you're seeing is that, every individual transaction is more or less getting backrun. And… And we trust the, the, the mempool, or the transaction supply chain, to pay back 90%… I mean, I think 90% is a stretch, but I think the ideal thing would be if they pay back 90% to the user. And then in… as I understand, the in-protocol and crypto mempool are lucid, I think it would be… back running would still be possible, but more, like, on the block. On the… on the one big transaction, background transaction, per block.

So… and then the argument is that that's… That, gives users potentially worse prices, one, because there could be still… they could still be off, and they could still have… They just get less of this back running. Proceeds, because it's… it's not a granular per transaction thing, but per block. And then the other… The other threat, I think, there is that you can have… That… that then that encourages, more… Probabilistic, or more, kind of, like… Sort of spamming to, to, on-chain, spamming to on… to… to try to get, to try to get these… Receipt, the… get the arbitrage profit. So ideally, I mean, just on a high, very high level, and not technically enough to understand in detail how it would work, but ideally, I think it would be cool if we could get to a design where

the… same… Per transaction back running. is… Possible in… and Lucid as well, so that, that, that, that efficiency is… is the same, but I think the first question is probably, is that even desirable? Like, there's also, I think, a case to be made that it's very inefficient to backrun every individual transaction, and maybe it just makes more sense from an economics point of view to have a more… have one big background transaction. So I guess that would be the first question about, do we even want that? And then second question is, is there a design, is there a modification possible that would allow that in the future?

Justin Florentine: I don't know the answer to the first question. That's kind of a Julian economist rig question, or maybe somebody else has an answer for that. Regarding the second part of it, I think…

Anders Elowsson: Yes, answer.

Justin Florentine: Oh, go ahead, Anders.

Anders Elowsson: So, in the Lucid EIP, I have written a very, very long section about this, called Med and Welfare. And in this MEV Welfare, section, I… Because it's such a complex topic, so I need to go into a very deep… about, what we're dealing with, and I, I classify them into 3 different classes. Exogenous med, endogenous MEV, and exogenous MEV. And by doing so… and what we… what you are talking about is, endogenous map. And… and… And what we do in Lucid is that we provide, the, the Keap publisher to, to, to bundle its transactions. And… It can then place the background transaction directly after the transaction that perhaps will provide the… Out to arbitrage.

And… by doing so, we sort of facilitate easy backgrounding. In… in Lucid. And so what we can say is that, of course, this would mean that there would be some more on-chain searching. To ensure that when you backrun your transaction, because you cannot know beforehand exactly the state of the pool, the various pools that you want to execute against when you backrun. So there will be a little bit more on-chain searching in this background section that will query the different pools, and to ensure that it tries to execute a… A good, background shade that provides the highest arbitrage. And, One way… one… two reasons why we think that this is desirable and sufficient is that, first of all, we can say that we are increasing in Ethereum the amount of compute.

That we can execute during a block. Specifically. we'll be able to scale compute by easily, I don't know, 10x or something like that. This means that on-chain searching, Yeah, it's feasible to do some on-chain searching. And second of all, we… we are not… Like, it feels… almost desirable to move some of the settlement on Ethereum into the, you know, the… the on-chain domain, like, into the composer domain, and sort of encouraging, various, indexes to allow for these, on-chain background transactions. So, I think that was the first question you had. Right. Something like that, was it? Or was it something else?

Luis: Yeah, no, I think it's… So… Mmm… But in theory, it could be possible, right, to… To… there's not… it's not… it's not something that we… that is inherent to… onto in-protocol and creative inputs, it is more like, you would say Lucid has Deliberately made that decision because it's sort of like… Desirable to bring more searching on-chain, to bring, kind of, like, routing on-chain. So yeah, I think that's fair from Lucid. I just think we should… then we need to, like, explain that a lot, and… And I think it would also be good… I think… Yeah, just think, like, there's gonna be a bunch of people who are against that, right, and going to say it's…

It's less efficient, and creates spamming, and… Yeah, so… just, like.

Gottfried Herold: I mean, there is one thing I want to add here, is that in principle, there's also another way to sort of facilitate this, which we do not want, which I'm not sure how you can actually prevent, which is that because the current Lucid design has, a free option problem, that someone who wants to backrun basically just basically tries to bring a Lucid transaction in, or maybe several, with different amounts of sort of traded stuff. And then selectively exercises their free option, which Lucy basically gives up by not releasing their keys, to basically selectively, after, sort of, the other keys, sort of, have been released, to decide whether to release their own keys to either make a back running transaction or not.

That's another, basically, way you could do this, which we do not want.

Luis: Interesting, so that… that means it… it's possible, actually. Just… not as… not a… it's like a… Right?

Anders Elowsson: As far?

Gottfried Herold: As far as I understand, yes.

Anders Elowsson: Yeah, so if you want to place a background transaction with option, you have to place it after the bundle that has executed.

Gottfried Herold: Yes. Yes.

Anders Elowsson: transaction that induced the map, executed. And this means that in your bundle, you can place your transaction, with the background in transaction following directly after. So… so… so from this perspective, it is true that, there is an option to execute, to execute some optionality towards the end of the top of block. Among these lost commitments, and we can expect them to do so. And they may, for example, search for backrunning opportunities, or for exogenous map that has emerged during this time that we have waited. And in that case, they need to select the release keys for that. And, And so, what I would address then is that, first of all, we have an intact opportunity for every sender to compose their own background and trades directly after the transaction. So there's no one that can come in and…

rely on their optionality to… to… to make the… The transaction execute faster. And… how… maybe I could add two more things. One thing I would add is that, first of all, we limit the damage at the protocol level from this optionality, in the sense that If you, indeed, do not execute your transaction, then this gas that you have reserved can't be used by any other transaction. So you do not remove scaling. By, by doing this, optionality thing. And then, I can also mention that, What was it more I wanted to say? I don't remember. Yeah, but…

Gottfried Herold: I mean, it does not cost gas for execution, but it still consumes resources as far as network resources are concerned.

Anders Elowsson: Yeah, but you have to pay the full gas limit for your.

Gottfried Herold: Yeah, yeah, yeah.

Anders Elowsson: That did not reveal.

Justin Florentine: So I spoke, you wanna pipe in?

soispoke: Yeah, I think there are, like, quite a few questions and answers in there, like. If the question was also about, like, whether you can, you know, have this sort of, like, separate lanes with first all the encrypted transactions and then the plaintank transactions, or can you, like, interleave them and sort of, like. Let people insert plain text transactions after encrypted transactions. And I think there, the design space is, like. more open than, it seems. Like, I feel like you could actually, like, interleave them, and that will maybe, like, leave space for, like. plaintext transactions that are, like, I don't know, backgrounding… optimistically, like, backrunning ones that are encrypted or something. I don't see why you would have, like, a sort of, like, strict separation between, you know, the encrypted, sort of, like.

massive bucket and the rest. I'm not sure if there is a reason, but, like, one thing it does introduce is, like, you know, you have, like, the encrypted bucket of transactions, and then people will, or, like, might, actually fight for having the transaction that comes right after it, and that tries to sort of, like. back runs, like, everything that's left, in terms of, opportunities from this whole bucket. So… so yeah, instead of, like, inserting transactions. Right after, you know, some encrypted transactions, and trying to backrun specific more, like, more specific, transactions, so I do think it makes a difference. And I do think, intuitively at least, it feels like… having interlived plain text and encrypted transactions makes sense to me.

Anders Elowsson: I don't see why this brings any benefits, or the benefits it brings are very marginal relative to the cost associated with it, I think. But that's a deep question related to the overall design. I would further say, So, what I describe in the Lucid, in this MEV Welfare section, is how you, in your bundle, you can either put the background transaction directly after your transaction. Or the bundle can put lost in the entire bundle, a search that holistically, on-chain searches for all the math that may have emerged from the transactions in the bundle, and then backgrounds it and distributes it back to the transactors. Responding to the question in the cost is that you have to do a completely different design.

If you interleave. it… Well, and I mean, if you… if you want to have a public plane transaction, Then, this means that you reveal what the… the seal transaction is gonna do, because you have to query certain pools about certain prices. So it's not clear to me that, I still don't understand, the benefits.

soispoke: Well, I think the benefits is… Comes back to the question of, like, trying to… compete to have, like, one plain text transaction after, like, every other encrypted transaction that was… that is sort of, like, set in stone, compared to… You know, picking… some transactions you think you can backrun and try to interleave your plain text transactions there. And I think it does make a difference. Like, instead of having this sort of, like, huge competition concentrated on one specific spot at the end of all encrypted transactions. I feel like it does make a difference, and then… yeah, the design will need to change, like, that's what I picked for the sort of, like, encrypted frame transactions post I published. It's,

It's same slot, and it's interleaving, you know, plain text and encrypted transactions, and it is meaningfully different, and it does have some, you know, things we will need to really think through, because it changes a bit, like the EPBS. model, and where you actually commit very strictly to a block hash. Here, yeah, here you commit to, like, a block hash, but also, like, an ordering, and so it's a sort of, like, weird mix between a block and a slot auction, but I feel like it's definitely worth considering, because then you get the same slot, and you get the Interlift transactions benefit. I agree, like, it's not, like, a small change, but… I think it needs to be, like, carefully, sort of, like, considered.

Justin Florentine: Yeah, I… I agree with that. I think it's very interesting. I guess the thing that I question is the benefit, actually, that you end up getting from it, right? Because once you're already committed to the ordering, and you're blind as to the encrypted transactions. How do you effectively take advantage of it? You know what I mean? Like, you can't really… you can't really recover that background efficiency that's being claimed.

soispoke: I mean, you're blind, but there are some metadata leakage, right? Like… you can, I don't know, you can try to guess the IP of the transaction center, or you can sort of just, like, see some of the fields or look at the market and sort of, like, try to predict what would the encrypt… like, what are the sort of, like, encrypted transactions doing based on the state of the market and the state of pool, so… You know, even if you have few sort of, like, the information is not that large, I agree, but you can still make educated guesses about what's going on and try to compete, to extract value from what was going on, right?

Luis: I think there could also be… Couldn't it also be… Kind of opening the field for, then, let's say, like. Users who are open to sharing the details about their transactions in order to like… So, then we have this hybrid, where a user would say, I am open to, kind of, I'm sharing some of my introduction details with, builders or… or, like, a TEE, and then they see my… they see details and can background, accordingly, and I just give… I just tell them the rule is. You're not allowed to, front run, but you're allowed to backrun? That's… that's a question.

soispoke: Yeah, I think… I think that's a potential case.

Anders Elowsson: I don't understand how it differs from… if I compare with Lucid. In Lucid, you… you… you already know the… I mean… Maybe, okay, maybe I can say it like this.

Mark Holt: Yeah, well, the difference is, it all happens.

Anders Elowsson: The… the… the… at the, at the last, transaction that's executed among the regular transactions. You already know the post state. the builder knows. So, so from that perspective, The first, the first decrypted transactions may, execute, Knowing the post state, and can also get hints from the builder in the same way. And then…

Mark Holt: Well, you've got to commit to the order, right?

Anders Elowsson: What was it?

Mark Holt: Builder's got to commit to the order, so they can't change the block.

Luis: I think the alternative design would be they could change, and could interleave transactions.

Mark Holt: Well, yeah, so that's the question. I mean, but this is a bit of a weird conversation, right? Is… is… in a… in a more traditional financial market. All of this stuff you're talking about isn't done by the block builder in some private space. The back running, which is market impact, generally comes out to everybody in the marketplace, because they can see the market data together. And then they compete for the next action. The kind of argument that You've got to protect backrunning for some… Privileged entities in the network. Isn't… you know, economically, it's not looking at the economic… the network economics, where actually you want to share the back running information More widely, because you let all market participants participate in the,

In the… in the information gathering. Now, one of the issues there with, kind of, the way blockchain markets work at the moment is they don't really have a great market data mechanism. If you had blockchain nodes generating market data at block time. You'd basically… you'd be go… you'd be giving everybody the same opportunity to see the data and then contribute to the next block.

Justin Florentine: Yeah, so can I just parrot that back? rephrasing it is that there's a timing difference. Some people have a different granularity of timing than others.

Mark Holt: Correct, yeah.

Justin Florentine: And the backgrounding could be thought of as… On the granularity of blocks instead of transactions, but we are kind of framing our thoughts here, from the builder's perspective, and really thinking about it per transaction.

Murat Akdeniz: Hey everyone, the other nuance here… my name is Murad from Primab, by the way. The other nuance here is that in regular markets, they don't return it back to the user, right? So here you have a regime where you're kind of trying to return 90% to the user, which is why you can't just open it up, because then it's whoever, you know, closed Opportunity.

Mark Holt: Well, that's because you're bribing everybody on the network. Right? So basically what you've got is a rigged market, and you're making it palatable by paying certain participants, i.e. the people who've done… because by users, you're returning it back to the people who submitted transactions in that block, right? And you're doing that at the cost to everybody else in the economy.

Anders Elowsson: Yeah, so, so what… What Mark is saying is that there's no, like, protocol welfare about having the builder interleave transactions, if I understand you correctly. which I… if I… if that's… that my understanding is correct, that… then I agree that there seems to be very little protocol welfare from that perspective. And we… we may add also that, Yeah, we could even have the… we may add that the reason why we would want the builder to have a sort of control of a section of the… a contingent section of the slot is to reduce, you know, this on-chain searching. And this is achieved by having you know, a contingent section of regular transactions. So that's a protocol welfare that we can say that, okay, it's good that the builder can control some part of the block, and just, you know, revert… do revert off-chain for those who wants that. And then we have the encrypted transactions where they bundle to do their back running as they wish.

Luis: Would it be fair to say that the not interleaving is… is probably better in terms of protocol and overall welfare, and the interleaving is probably more geared towards the people who want to search, and the people and their needs, right? Is that something where the trade-off… and I think it could make sense to do a trade-off where you say. We know that front-running is bad, make front-running impossible, but otherwise be as open to, To searches and their demands, and then the people who want to trade, basically, as possible.

Mark Holt: Yeah, I mean, I think the thing is, and I'm just saying this coming from a high-frequency trading background in normal markets, it's… you get… Got a 12-second block. If you're a searcher, you're far… you're far better off searching for bigger wins at a higher level of time granularity than actually focused on what you get with an intra-block chain trade. you know, if you assume… if you assume… so there's a couple of issues here, is I think the reason for encrypted mempools is to… try to open the network up for other participants, essentially, who are avoiding the network at the moment, because it basically has MEV on it. So… The… and for those other participants, they're likely to be…

You know, they're likely to hold stronger positions. So, you know, the searching they'll pay for is profitable trades on a, you know, on a… On a higher time scale. And, I mean, actually, I would argue that That might actually be more profitable for the searchers as well. Essentially. Because it's a bit like the whole ecosystem's got fixated on MEV. a bit like… You know, the financial world got fixated on high-frequency trading, because it seems like money for nothing. But in practice, there's only a… you know, you can only apply a relatively small amount of capital. To… to the… to the money that you make in… inside of the block message, which is one of the reasons that there is concentration of block builders is it's a niche thing, financially, because it's got, you know, there's a cap to the amount of capital that you can trade like that.

So, most people don't bother participating. You know… Either they… either they're too big or they're too small, which is why you've got, you know, the block builder niche.

Justin Florentine: Anders? You sub your hand up if you were, trying to say something.

Anders Elowsson: So, I just wanted to add also that I think that the price we're paying for for this interleaved design, where we have, you know, just a pause and waiting for keys to be released, I think it's a very high price. for this one-slot design, and I think that the one-slot design we describe in the Lucid AIP as a future potential improvement that sort of just extends the Lucid EIP is the correct way if you want to do a one-slot design. And it works like this. So you… You do just as in Lucid. But you do the second part of the slot as this sort of, you know, semantic block shunking, where you, where you have… you first execute all the regular transactions.

Then… and you have the release of the keys. Then, in the second half, and this is also quite similar to EIP8105, but not exactly, but anyway, then in the second half, you have the builder release a second pile. For the decrypted transactions that have been decrypted, And then you have, And then you have, everyone executing those transactions. And the builder can then also… By the end, after this section, include regular transaction. regular transactions after this chunk of, of, decrypted transactions, allowing us to not waste gas, because if we commit before, before, the… if we commit as in this, this other design. and then someone does not release the key, then you waste the gas for the rest of the block. And this opens up for a griefing against the builder, because now, if I'm a builder and someone,

Doesn't, doesn't, you know, just submit a transaction, and I don't have to pay for it. Then, it's just gonna waste the gas in my block. Yeah, and it's not.

Murat Akdeniz: But in terms of the price I'm getting on a swap. Basically, like, the encrypted transaction becomes a second-class citizen.

Justin Florentine: Is it the encrypted transaction that becomes a second-class citizen, or is it subsequent transactions in the block, because the encrypted transaction denied price discovery?

Murat Akdeniz: I guess there's a second and a third-class citizen, it's a good point. So those become the third class citizens, yeah.

Justin Florentine: Godfrey?

Gottfried Herold: Yeah, I just wanted to add something on this kind of, basically interleaf transaction things. I mean, the alternative proposal by Tuma basically is, has… is a… well, basically, it uses same slot, basically committing, and sort of… it's basically a same slot design, whereas Lucid is not. I mean, in principle, nothing would stop you to do a interleaf design also by… by a Lucid, which is not slot. You would just have a second… you would have another round, or another round of interaction, where basically the builder first commits to transaction ordering. and also basically commit to the non-encrypted transactions, by sort of honoring some kind of ordering rules within the encrypted transactions that are sort of determined by the, previous block's, inclusion lists. You could do that and still have some of the… basically make some hybrid approach between the two.

Just saying that this kind of… this interleavedness is not really tied to, same slot.

soispoke: Yeah, I completely agree. I think those are, like, two orthogonal dimensions that we can discuss. I think, for me, like, the same slot versus two slots is… way more about timing. Also, I mean, it's, you know, if you don't have time for, like, key reviews and stuff like this to happen within, like, one slot, then you might want to move towards two, like, a two-slot design, but, I mean, of course, like, if you can actually make it work within one slot, it's… it's just, like, strictly better, I think. And then the interleaved versus separated is also, yeah, completely orthogonal to that, and you can have, like, a one-slot or two-slot design with interleaved or, like, buckets,

I think those are, like. More open, in my mind at least, to what's… Been sort of, like. said, and I think there could be, you know, dedicated time to think about one slot versus two slots, but also, like, entirely versus buckets, and that's… yeah. That's basically why I published this post, it's a… there are, like, 3 dimensions. There is the interlift, there is the same slot, which we already discussed, which is… so it's great. And then there is the, sort of, like, it builds on frame transactions, right? So… If, you know, if friend transactions actually come through, there is no point, at least to me, in sort of, like, shipping another additional transaction type that is not, sort of, like, PQ compatible, and we might as well just, like, build, this sort of, like, encrypted frame transaction on top of frame transactions, because it's basically what it was

built for, right? It's to avoid bringing, like, more transaction types, which I think makes sense. So, but those are, like, basically the three things that… that sort of, like, my design introduces… introduce, I think.

Anders Elowsson: Yeah. No, it's… I think it's good to have frame transactions as an option. We describe it in the Lucid API, we describe it as… Essentially, just taking the… the…

Justin Florentine: that it's necessary?

Anders Elowsson: kit. just taking the SE ticket and, and then, putting it as the second frame. This was, what Gottfried recommended for, for this, for this… I don't know if he has any comment, or if it was inspired by Thomas, or how that transpired, but anyway, so, so… But I think that this is, Plain obvious that we can do so.

Gottfried Herold: Yeah, that's not so clear, actually. There is the… problem with the frame transaction framework. The frame transaction framework feels to me, like, not perfectly compatible with the two-slot design that Lucid currently has, because the frame transaction design basically makes the assumption that the individual frames that comprise one big frame transaction are basically executed one after another. In particular, sort of the verification part of the frame transaction and the actual execution part of the transaction are sort of immediately following in another. And in the way we would, do a current… the current Lucid design works, you have basically the authentication, which is basically, part of the, seal trans… of the, of the ST, of the, of the, of the, of the ticket, and the actual transaction happened in different blocks, and that is kind of very, very hard to sort of match with the way,

the frame transaction, the current frame transaction EIP works, at least not without, sort of, making this much more flexible. That's one big issue as a year.

Anders Elowsson: So, if we did, if we did this, semantic shunking. I guess then it would work, right? The semantic shunking, idea. So the semantic shanking idea is that you first, have, have, You, you, you, you have the, You first have the commitments in the beacon block. Then you have the first chunk of regular transactions that execute with the ball. And then, secondly, you have a second chunk. That consists of the, the… this… in this case, it will be the frame transactions done. Execute in the second half.

soispoke: So yeah, that design makes sense, I think it works, but, like, the… it obviously introduces, like. two payloads, basically, within one slot. And you have to deal with, like, two different network objects, and maybe two deadlines, and that feels… Like, it's definitely some additional complexity that… needs to be taken into account compared to a design where you have, yes, you know, a mix of, like, plain text and encrypted transactions, but at least you have one, sort of, like, payload, and then, Yeah, I feel like that's the main difference.

Gottfried Herold: I mean, what… kind of the natural way, basically, would be, in my view, would be to have basically one frame transaction, which basically has one frame that goes in the previous slot. And that basically authenticates some stuff, including the frame transaction itself, and basically… and it also authenticates the second part… second frame, and that second frame only executes in the next block, and it basically has some kind of pointer or whatever to which frame transaction actually authenticated it in the previous block or something. It just means a bigger change to the way frame transactions work.

soispoke: I mean, yeah, that's, like, cross-lot frame transactions, it feels like it's… I mean, I haven't thought about it, like, very much, but it feels quite huge in terms of, like. rethinking the whole… you know, it's one thing to separate validation from execution, which is very nicely done with, like, from transactions, but, like, to have this sort of, like, validation done in one block, and then the execution done in another block with some sort of link between the two feels like a stripe at this point.

Gottfried Herold: Yeah, I mean, I fear where we would need it, if you actually want to make at least the current two-slot Lucid design compatible with frame transactions in a nice way, where you basically don't have two separate validation logics, and in particular, where you want to, benefit from the fact that we have programmable, validation logic that… for PQ security, I think you have to do something like that.

soispoke: Yeah, yeah, yeah, but I mean, hopefully we can just, like, make it work within one slot, and just… it simplifies.

Gottfried Herold: Yeah, I'm not so sure about that. I'm kind of skeptical about making it work as in one slot because of the introduced latency, but yeah, we wouldn't need… probably, we actually need some real-world data for that.

soispoke: Yeah, yeah. I agree. I mean, that's also my concern. It would need to be, like, very, sort of, like, heavily benchmarked, but I don't know. My intuition would be, like. why wouldn't we go with, like, some, like, one-slot design, just, like, if we can, just because it's so much cleaner, like, you see all the sort of, like, transactions being sort of, like, committed to at the same time, and then, you know, the keys are revealed, and then… it just feels, like, more natural for me to think about it, but of course, yeah, if it's just, like, impossible to do it in terms of… Timing and latency, then… yeah, we have to… but that actually, interestingly, interacts with the shorter slots, right? Like, for this, we will not want shorter slots, I guess.

Murat Akdeniz: Well, we actually assessed this, and if we simply give the builder the optionality to include it in same slot. granted that keepers release keys, you know, either out of protocol or however they choose, then they're actually able to, you know, include them in the same slot. And then, you know, if something goes wrong, etc, then they just default to N plus 1, which is already the case. So, this was the proposal that, you know, we brought in the Telegram group, so… I mean, it seems largely aligned with, what Both people are saying here, wondering if there's any concerns regarding that.

Justin Florentine: Alright, we are.

Gottfried Herold: I mean…

Justin Florentine: on time, but, go ahead if you had an answer for that, Guthrie.

Gottfried Herold: Yeah, just saying, I mean, at least a concern I had would be that, I mean, at least for frame transactions, frame transaction compatible transactions would need… would… would basically be forced to use that. So this optionality would go away once you use frame transactions or any kind of PQ signature, at least the way we want to introduce PQ security. So it's not really an optionality thing at some point anymore.

Murat Akdeniz: Well, I mean, if you want good execution, it's not really optional anyway, right? So… but the current design makes it so that if you want good execution, then you cannot use encrypted transactions, because you're always, you know, N plus 1.

Anders Elowsson: Yeah, if you want to… if you want to extract an exogenous map, this sort of map from from, based on what happened during the last slot, yeah, then you will likely not be able to use, Lucid, particularly well, for example. But, but the, the thing is that, I mean, this has both benefits and drawbacks. It's not like it's, It's not like this is critical for people that just want to include their transactions with this endogenous MEV.

Murat Akdeniz: Yeah, but the approach, you know, kind of allows for both, essentially, right? We're essentially saying Lucid can like, it's agnostic to whether it's slot N or N plus 1. If you have the keys, etc, you can do N, and if you don't, then N plus 1 is fine.

Anders Elowsson: No, yeah, but, I mean, you have to… No, it's… I mean, there are very… there are several considerations that has to match. One, you don't want to delay execution, we don't want to degrade scaling. Two, you have to… you have to have the panel there, so those two interact. Then, yeah. And I mean, I don't… it's not clear to me what the proposal is from you exactly, so it's…

Mark Holt: Americans.

Anders Elowsson: evaluated.

Murat Akdeniz: Yeah, maybe I'll do a write-up on it as well, but, you know, generally the decryption time is about 80 milliseconds, so as long as blocks are, you know, 130 milliseconds or longer, we're good from a scaling perspective. But… Yeah, I'll do a write-up.

Justin Florentine: Right. Thank you for that.

Anders Elowsson: But you have to have, Everyone has to observe the availability of the keys.

Murat Akdeniz: I see, so that might be a key, key difference between the same slot and N plus 1.

Justin Florentine: Yeah, it's more about key distribution, let alone… not so much decryption time. Cool, so we're at time. Thanks to everyone. We should get a transcription here, and we should get an AI summary of it. I'll go over it to make sure that it's not total slop. We'll attach it to, encrypted Mempool. Yeah, see you on Discord in the Encrypted Mempool channel, various telegrams, et cetera, et cetera. Thank you so much, everyone.

Luis: Thank you.

Murat Akdeniz: Thanks, guys.

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