Justin Florentine (Besu):So, encrypt in the mempool!
Transcript
Justin Florentine (Besu):This is fun. Okay, we've got our EIP number for the Lucid design. That's cool, 8184.
Justin Florentine (Besu):Good stuff.
Justin Florentine (Besu):Good stuff.
Justin Florentine (Besu):New additions to the agenda… wow, okay. Improved back running efficiency.
Justin Florentine (Besu):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…
Justin Florentine (Besu):On-chain versus off-chain implementations, trust performance implications, that's a good one.
Justin Florentine (Besu):Back running efficiency, let's see… Luis, are these your suggestions?
Luis:Yep.
Justin Florentine (Besu):I think that… Anders, welcome.
Justin Florentine (Besu):So I think I wanted to… there's, there's 3 things that I wanted to cover, specifically, observability.
Justin Florentine (Besu):Right? A demonstrator stack, And then… I wanted to talk about… hey, Anders, I wanted to talk about,
Justin Florentine (Besu):So I spoke's recently dropped proposal for encrypted frame transactions. It's literally just got published.
Justin Florentine (Besu):I don't know.
Justin Florentine (Besu):20 minutes ago, half hour ago.
Justin Florentine (Besu):So, I guess, I guess let's start with the top, from the top.
Justin Florentine (Besu):A demonstrator in observability.
Justin Florentine (Besu):If we put the notion of…
Justin Florentine (Besu):encrypting the mempool and the design for encrypting the mempool to the side. What would we want to build?
Justin Florentine (Besu):To demonstrate the lack of an encrypted mempool.
Justin Florentine (Besu):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
Justin Florentine (Besu):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.
Justin Florentine (Besu):So that can be the thing that we test against, iterate against, and… and evolve.
Justin Florentine (Besu):So,
Justin Florentine (Besu):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
Luis: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.
Luis:Transactions, and just kind of, like.
Luis: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.
Luis:Because, kind of, like, in principle, that is an out-of-protocol implementation of an encrypted memo, right? In theory, we could…
Luis:Kind of like… Showcase what happens if you send a
Luis:Something we've been thinking about in the past is just running a… Generic frontrunning… Frontrunner…
Luis:But on Gnosis chain, and front-running all transactions that don't go through the encrypted mempool.
Luis:So, but yeah, just high level, I think the Gnosis chain implementation could be used.
Justin Florentine (Besu):So, I'm curious, before we started talking about Gnosis, you were saying, you know.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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…
Luis: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.
Luis:Monte Carlo-wise, simulated transactions, and different ordering, different ways to order, and, like.
Luis:Also this, like, the topic of…
Luis:How efficient is back running, per transaction backrunning, or per block back running?
Luis:But I can… I could share… I could share the link.
Luis:But I think maybe it's a precursor to what you're thinking.
Justin Florentine (Besu):Interesting. Stefan, you have a note here in chat. Would you care to elaborate?
Justin Florentine (Besu):Yes, depending on the timing, we could consider building on top of that.
Justin Florentine (Besu):A builder for EPBS. Okay.
Stefan Starflinger:Yeah. So… In general, we need just a sequence of transaction, from an AMM,
Stefan Starflinger: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.
Stefan Starflinger:And we just need a builder for that, either, like, simulating is a good approach.
Stefan Starflinger:But if we have a builder through EPBS anyways.
Stefan Starflinger:We could consider using that. That's just an idea.
Justin Florentine (Besu):Okay, Luis, can you, maybe take an action item to talk to Yannick and see if what he's got
Justin Florentine (Besu):It's been published anywhere?
Justin Florentine (Besu):If there's a repo for it, we can take a look at it and try to run that.
Luis:Yep.
Justin Florentine (Besu):And then… maybe see how the builder fits into it for Stefan's suggestion.
Luis:Yep.
Justin Florentine (Besu):Does it have…
Justin Florentine (Besu):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.
Justin Florentine (Besu):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 (Besu):Okay Cool.
Justin Florentine (Besu):Is the AI taking notes? It is being transcribed, hooray! Great, I don't have to actually take notes.
Justin Florentine (Besu):This is… this is the… this is the future that we were promised.
Justin Florentine (Besu):Okay. Cool.
Justin Florentine (Besu):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…
Justin Florentine (Besu):I think defining some of the efficiencies in economics, would you care to elaborate on…
Justin Florentine (Besu):The need to improve… To better define the backgrounding efficiency.
Luis:Yeah, so this is triggered by,
Luis:I think Data Always from… from Flashbars, right, who said… who made this point that… The…
Luis: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.
Luis:And… And we trust the, the,
Luis: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.
Luis: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.
Luis:On the… on the one big transaction, background transaction, per block.
Luis:So… and then the argument is that that's…
Luis:That, gives users potentially worse prices, one, because there could be still… they could still be off, and they could still have…
Luis:They just get less of this back running.
Luis:Proceeds, because it's… it's not a granular per transaction thing, but per block.
Luis:And then the other… The other threat, I think, there is that you can have…
Luis:That… that then that encourages, more…
Luis:Probabilistic, or more, kind of, like…
Luis:Sort of spamming to, to, on-chain, spamming to on… to… to try to get, to try to get these…
Luis:Receipt, the… get the arbitrage profit.
Luis: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
Luis:the… same… Per transaction back running.
Luis:is… Possible in… and Lucid as well, so that, that, that, that efficiency is…
Luis: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
Luis: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 (Besu):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.
Justin Florentine (Besu):Regarding the second part of it, I think…
Anders Elowsson:Yes, answer.
Justin Florentine (Besu):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.
Anders Elowsson:And in this MEV Welfare, section, I…
Anders Elowsson:Because it's such a complex topic, so I need to go into a very deep…
Anders Elowsson:about, what we're dealing with, and I, I classify them into 3 different classes. Exogenous med, endogenous MEV, and exogenous MEV.
Anders Elowsson:And by doing so… and what we… what you are talking about is, endogenous map.
Anders Elowsson:And… and… And what we do in Lucid is that we provide,
Anders Elowsson:the, the Keap publisher to, to, to bundle its transactions.
Anders Elowsson:And… It can then place the background transaction directly after the transaction that perhaps will provide the…
Anders Elowsson:Out to arbitrage.
Anders Elowsson:And… by doing so, we sort of facilitate easy backgrounding.
Anders Elowsson:In… in Lucid.
Anders Elowsson:And so what we can say is that, of course, this would mean that there would be some more on-chain searching.
Anders Elowsson: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.
Anders Elowsson: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…
Anders Elowsson:A good, background shade that provides the highest arbitrage.
Anders Elowsson:And,
Anders Elowsson: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.
Anders Elowsson:That we can execute during a block.
Anders Elowsson:Specifically.
Anders Elowsson:we'll be able to scale compute by easily, I don't know, 10x or something like that.
Anders Elowsson:This means that on-chain searching,
Anders Elowsson:Yeah, it's feasible to do some on-chain searching.
Anders Elowsson:And second of all, we… we are not… Like, it feels…
Anders Elowsson:almost desirable to move some of the settlement on Ethereum into the, you know, the…
Anders Elowsson:the on-chain domain, like, into the composer domain, and sort of encouraging, various,
Anders Elowsson:indexes to allow for these, on-chain background transactions.
Anders Elowsson:So, I think that was the first question you had.
Anders Elowsson:Right. Something like that, was it? Or was it something else?
Luis:Yeah, no, I think it's… So… Mmm…
Luis:But in theory, it could be possible, right, to…
Luis:To… there's not… it's not… it's not something that we… that is inherent to…
Luis:onto in-protocol and creative inputs, it is more like, you would say Lucid has
Luis:Deliberately made that decision because it's sort of like…
Luis:Desirable to bring more searching on-chain, to bring, kind of, like, routing on-chain.
Luis:So yeah, I think that's fair from Lucid. I just think we should… then we need to, like, explain that a lot, and…
Luis:And I think it would also be good… I think…
Luis:Yeah, just think, like, there's gonna be a bunch of people who are against that, right, and going to say it's…
Luis: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.
Gottfried Herold: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.
Gottfried Herold: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.
Luis: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.
Gottfried Herold:Yes.
Anders Elowsson:transaction that induced the map, executed.
Anders Elowsson:And this means that in your bundle, you can place your transaction, with the background in transaction following directly after.
Anders Elowsson:So… so… so from this perspective, it is true that, there is an option to execute,
Anders Elowsson:to execute some optionality towards the end of the top of block.
Anders Elowsson: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.
Anders Elowsson:And in that case, they need to select the release keys for that.
Anders Elowsson:And,
Anders Elowsson: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…
Anders Elowsson:rely on their optionality to… to… to make the… The transaction execute faster.
Anders Elowsson:And…
Anders Elowsson: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
Anders Elowsson: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.
Anders Elowsson:By, by doing this, optionality thing.
Anders Elowsson:And then, I can also mention that,
Anders Elowsson:What was it more I wanted to say?
Anders Elowsson: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 (Besu):So I spoke, you wanna pipe in?
soispoke:Yeah, I think there are, like, quite a few questions and answers in there, like.
soispoke: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.
soispoke:Let people insert plain text transactions after encrypted transactions.
soispoke:And I think there, the design space is, like.
soispoke:more open than, it seems. Like, I feel like you could actually, like, interleave them, and that will maybe, like, leave space for, like.
soispoke:plaintext transactions that are, like, I don't know, backgrounding…
soispoke: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.
soispoke: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
soispoke: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.
soispoke:back runs, like, everything that's left, in terms of, opportunities from this whole bucket. So… so yeah, instead of, like, inserting transactions.
soispoke:Right after, you know, some encrypted transactions, and trying to backrun specific more, like, more specific,
soispoke:transactions, so I do think it makes a difference.
soispoke:And I do think, intuitively at least, it feels like…
soispoke: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.
Anders Elowsson:But that's a deep question related to the overall design.
Anders Elowsson:I would further say,
Anders Elowsson: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.
Anders Elowsson: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.
Anders Elowsson:Responding to the question in the cost is that you have to do a completely different design.
Anders Elowsson:If you interleave.
Anders Elowsson:it… Well, and I mean, if you… if you want to have a public plane transaction,
Anders Elowsson:Then, this means that you reveal what the…
Anders Elowsson: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,
Anders Elowsson:the benefits.
soispoke:Well, I think the benefits is…
soispoke:Comes back to the question of, like, trying to…
soispoke: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…
soispoke:You know, picking…
soispoke: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
soispoke: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,
soispoke: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
soispoke:it changes a bit, like the EPBS.
soispoke: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
soispoke: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…
soispoke:I think it needs to be, like, carefully, sort of, like, considered.
Justin Florentine (Besu):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.
Justin Florentine (Besu):How do you effectively take advantage of it?
Justin Florentine (Besu):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…
soispoke: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
soispoke: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…
soispoke:You know, even if you have few
soispoke: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…
Luis:Kind of opening the field for, then, let's say, like.
Luis:Users who are open to sharing the details about their transactions in order to like…
Luis: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.
Luis:You're not allowed to, front run, but you're allowed to backrun?
Luis: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…
Anders Elowsson:you already know the… I mean…
Anders Elowsson:Maybe, okay, maybe I can say it like this.
mark:Yeah, well, the difference is, it all happens.
Anders Elowsson:The… the… the… at the, at the last,
Anders Elowsson:transaction that's executed among the regular transactions. You already know the post state.
Anders Elowsson:the builder knows. So, so from that perspective,
Anders Elowsson:The first, the first decrypted transactions may, execute,
Anders Elowsson:Knowing the post state, and can also get hints from the builder in the same way.
Anders Elowsson:And then…
mark:Well, you've got to commit to the order, right?
Anders Elowsson:What was it?
mark: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: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.
mark:All of this stuff you're talking about isn't done by the block builder in some private space.
mark:The back running, which is market impact, generally comes out to everybody in the marketplace, because they can see the market data together.
mark:And then they compete for the next action.
mark:The kind of argument that You've got to protect backrunning for some…
mark:Privileged entities in the network.
mark: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
mark:More widely, because you let all market participants participate in the,
mark: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.
mark:If you had blockchain nodes generating market data at block time.
mark: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 (Besu):Yeah, so can I just parrot that back?
Justin Florentine (Besu):rephrasing it is that there's a timing difference. Some people have a different granularity of timing than others.
mark:Correct, yeah.
Justin Florentine (Besu):And the backgrounding could be thought of as…
Justin Florentine (Besu):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: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
Murat:Opportunity.
mark:Well, that's because you're bribing everybody on the network.
mark:Right? So basically what you've got is a rigged market, and you're making it palatable by paying
mark: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?
mark:And you're doing that at the cost to everybody else in the economy.
Anders Elowsson:Yeah, so, so what…
Anders Elowsson:What Mark is saying is that there's no, like, protocol welfare about having the builder interleave transactions, if I understand you correctly.
Anders Elowsson: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,
Anders Elowsson: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.
Anders Elowsson:And this is achieved by having
Anders Elowsson: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
Luis: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.
Luis:We know that front-running is bad, make front-running impossible, but otherwise be as open to,
Luis:To searches and their demands, and then the people who want to trade, basically, as possible.
mark: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…
mark:you get… Got a 12-second block.
mark: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.
mark: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…
mark: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.
mark:So… The… and for those other participants, they're likely to be…
mark: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…
mark:On a higher time scale.
mark:And, I mean, actually, I would argue that
mark:That might actually be more profitable for the searchers as well.
mark:Essentially.
mark:Because it's a bit like the whole ecosystem's got fixated on MEV.
mark:a bit like…
mark:You know, the financial world got fixated on high-frequency trading, because it seems like money for nothing.
mark:But in practice, there's only a… you know, you can only apply a relatively small amount of capital.
mark:To… to the… to the money that you make in…
mark: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.
mark:So, most people don't bother participating.
mark:You know…
mark: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 (Besu):Anders?
Justin Florentine (Besu):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
Anders Elowsson: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.
Anders Elowsson: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…
Anders Elowsson:You do just as in Lucid.
Anders Elowsson: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.
Anders Elowsson:Then…
Anders Elowsson: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.
Anders Elowsson:For the decrypted transactions that have been decrypted, And then you have,
Anders Elowsson:And then you have, everyone executing those transactions. And the builder can then also…
Anders Elowsson:By the end, after this section, include regular transaction.
Anders Elowsson: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.
Anders Elowsson: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,
Anders Elowsson:Doesn't, doesn't, you know, just submit a transaction, and I don't have to pay for it.
Anders Elowsson:Then, it's just gonna waste the gas in my block.
Anders Elowsson:Yeah, and it's not.
Murat:But in terms of the price I'm getting on a swap.
Murat:Basically, like, the encrypted transaction becomes a second-class citizen.
Justin Florentine (Besu):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: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 (Besu):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
Gottfried Herold: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.
Gottfried Herold: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.
Gottfried Herold: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…
soispoke: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…
soispoke: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,
soispoke:I think those are, like.
soispoke:More open, in my mind at least, to what's… Been sort of, like.
soispoke:said, and I think there could be, you know, dedicated time to think about
soispoke: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…
soispoke: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…
soispoke:If, you know, if friend transactions actually come through, there is no point, at least to me, in sort of, like, shipping another
soispoke: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
soispoke: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.
Anders Elowsson: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…
Anders Elowsson:Essentially, just taking the… the…
Justin Florentine (Besu):that it's necessary?
Anders Elowsson:kit.
Anders Elowsson:just taking the SE ticket and, and then, putting it as the second frame. This was, what Gottfried recommended for, for this,
Anders Elowsson:for this… I don't know if he has any comment, or if it was inspired by Thomas, or how that
Anders Elowsson:transpired, but anyway, so, so… But I think that this is,
Anders Elowsson:Plain obvious that we can do so.
Gottfried Herold:Yeah, that's not so clear, actually. There is the…
Gottfried Herold: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
Gottfried Herold:execution part of the transaction are sort of immediately following in another.
Gottfried Herold:And in the way we would, do a current… the current Lucid design works, you have basically the authentication, which is
Gottfried Herold: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,
Gottfried Herold:the frame transaction, the current frame transaction EIP works, at least not without, sort of, making this much more flexible.
Gottfried Herold:That's one big issue as a year.
Anders Elowsson:So, if we did, if we did this, semantic shunking.
Anders Elowsson:I guess then it would work, right?
Anders Elowsson:The semantic shunking, idea.
Anders Elowsson:So the semantic shanking idea is that you first, have, have,
Anders Elowsson:You, you, you, you have the,
Anders Elowsson:You first have the commitments in the beacon block.
Anders Elowsson:Then you have the first chunk of regular transactions that execute with the ball.
Anders Elowsson:And then, secondly, you have a second chunk.
Anders Elowsson:That consists of the, the… this… in this case, it will be the frame transactions done.
Anders Elowsson:Execute in the second half.
soispoke:So yeah, that design makes sense, I think it works, but, like, the… it obviously introduces, like.
soispoke:two payloads, basically, within one slot. And you have to deal with, like, two different network objects, and maybe two deadlines, and that feels…
soispoke:Like, it's definitely some additional complexity that…
soispoke: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,
soispoke: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.
Gottfried Herold: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…
soispoke:I mean, I haven't thought about it, like, very much, but it feels quite huge in terms of, like.
soispoke: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,
Gottfried Herold: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.
soispoke: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…
soispoke:Timing and latency, then…
soispoke: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:Well, we actually assessed this, and if we simply give the builder the optionality to include it in same slot.
Murat: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…
Murat:I mean, it seems largely aligned with, what
Murat:Both people are saying here, wondering if there's any concerns regarding that.
Justin Florentine (Besu):Alright, we are.
Gottfried Herold:I mean…
Justin Florentine (Besu):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: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
Anders Elowsson:from, based on what happened during the last slot, yeah, then you will likely not be able to use, Lucid, particularly well, for example.
Anders Elowsson:But, but the, the thing is that,
Anders Elowsson:I mean, this has both benefits and drawbacks. It's not like it's,
Anders Elowsson:It's not like this is critical for people that just want to include their transactions with this endogenous MEV.
Murat:Yeah, but the approach, you know, kind of allows for both, essentially, right? We're essentially saying Lucid can
Murat: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…
Anders Elowsson: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.
Anders Elowsson:Then, yeah.
Anders Elowsson:And I mean, I don't… it's not clear to me what the proposal is from you exactly, so it's…
mark:Americans.
Anders Elowsson:evaluated.
Murat: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…
Murat:Yeah, I'll do a write-up.
Justin Florentine (Besu):Right.
Justin Florentine (Besu):Thank you for that.
Anders Elowsson:But you have to have,
Anders Elowsson:Everyone has to observe the availability of the keys.
Murat:I see, so that might be a key, key difference between the same slot and N plus 1.
Justin Florentine (Besu):Yeah, it's more about key distribution, let alone… not so much decryption time.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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:Thanks, guys.
Chat Logs
00:03:40
Anders Elowsson:HI
00:03:55
Anthony:👋
00:07:20
Stefan Starflinger:Pk is working on a builder for epbs depending on the timing we could consider building on top of that
00:10:01
Stefan Starflinger:Replying to "Pk is working on a b…"
https://github.com/ethpandaops/buildoor
00:15:25
soispoke:Practically there are definitely ways to interleave plaint text and encrypted txns (this is part of the encrypted frame txn design I published) https://ethresear.ch/t/encrypted-frame-transactions/24440
00:16:08
soispoke:Replying to "Practically there ar..."
This doesn’t change what Anders is saying about needing to use onchain searching
00:16:34
Justin Florentine (Besu):yes, but is it meaningful if their order was committed already prior to reveal?
00:17:03
soispoke:Well it avoids competition for doing the 1 backrun at the end of all encrypted txns
00:23:16
soispoke:What are the costs and benefits in your opinion?
00:23:28
soispoke:(Interleaved between separate buckets)
00:31:05
Potuz:if they could interleave txs they could signal the other ones on how to branch isn't it? you'd always want to be committed on one of the encrypted one and then reserve the right to execute it or not or pick branch of execution by interleaving the trigger.
00:32:07
soispoke:Replying to "if they could interl..."
The idea would be to commit to both plain and encrypted txns at the exact same time (if even if they are interleaved)
00:33:39
Potuz:Replying to "if they could interl..."
as long as the full ordering is committed that could work.
00:33:52
Gottfried Herold:I mean you could have interleaved txs in soispoke's design also for Lucid, but with the difference that essentially the builder only commits to the ordering (but WHICH encrypted transactions have to go through is still determined by a FOCIL-like mechanism)
00:34:46
soispoke:Replying to "I mean you could hav..."
Yes that’s the difference, which to be fair is a big one (because it changes the way ePBS commits to contents/ordering) but I think it’s worth considering
00:37:06
Potuz:is it me or Anders is the only one I can't hear?
00:37:12
soispoke:Replying to "is it me or Anders i..."
I can hear
00:37:15
Justin Florentine (Besu):Replying to "if they could interl..."
ePBS committing to something a little looser than a stateroot seems like a powerful unlock
00:37:28
soispoke:Replying to "if they could interl..."
I agree
00:37:45
Potuz:Replying to "if they could interl..."
how is the commitment going to be? the bid sends the ordering?
00:37:46
soispoke:Replying to "if they could interl..."
But just not something to take lightly
00:37:56
soispoke:Replying to "if they could interl..."
@Potuz yes
00:38:23
soispoke:Replying to "if they could interl..."
In the figure above you just have tx_ordering_root in the bid
00:44:12
soispoke:Yeah I agree, frame txns cleany separate validation and execution which is great for 1 slot but weird to think about for 2 slots
00:47:26
Anders Elowsson:Can’t we just have a sidecar to a ticket inside a frame tx
00:48:35
Potuz:Already FOCIL kinda kills shorter slots anyway
00:48:52
soispoke:Replying to "Already FOCIL kinda ..."
No I don’t think it does!
00:49:04
soispoke:Replying to "Already FOCIL kinda ..."
Probably not the right breakout room but happy to chat more about this
00:49:18
soispoke:Replying to "Already FOCIL kinda ..."
The tldr is: just do a separate BAL deadline
00:49:24
soispoke:Replying to "Already FOCIL kinda ..."
That reveals it earlier
00:49:47
Potuz:Replying to "Already FOCIL kinda ..."
I think you guys aren't equally afraid as I am with split views. Already ePBS is borderline crazy timing :)
00:50:17
soispoke:Replying to "Already FOCIL kinda ..."
Haha ok then let’s frame it as ePBS kills shorter slots 🙂
00:50:19
Potuz:Replying to "Already FOCIL kinda ..."
All the designs that are being thrown for encrypted txs seem quite impossible to me from the forkchoice perspective
00:50:25
Potuz:Replying to "Already FOCIL kinda ..."
with 12 seconds even
00:50:42
soispoke:Replying to "Already FOCIL kinda ..."
Ok yeah tbh I don’t have a good view on how much time it would take
00:50:48
soispoke:Replying to "Already FOCIL kinda ..."
To release keys etc
00:51:00
Justin Florentine (Besu):Replying to "Already FOCIL kinda ..."
ssf bro, 12 seconds are fine with instant finality
00:51:31
soispoke:Replying to "Already FOCIL kinda ..."
3SF is more the vibe these days (but still very nice)
00:51:34
Potuz:Replying to "Already FOCIL kinda ..."
gotta jump meetings, a pleasure seing y'all
00:51:51
soispoke:I have to go too, thanks for the discussion!
Summary
9 highlights
· 3 action itemsExperimental
Summary
9 highlights · 3 action itemsExperimentaleip status
- Lucid design assigned EIP-818400:02:36
design questions
- Per-transaction vs per-block backrunning efficiency debated; trade-offs discussed00:09:41
- Interleaved plain text/encrypted transactions vs separate buckets explored00:14:36
- Same-slot vs two-slot designs orthogonal to interleaving decision00:26:00
- Frame transactions compatibility with two-slot Lucid design unclear00:42:02
- Fork-choice timing concerns raised for encrypted mempool designs in 12s slots00:50:25