Encrypt the Mempool Call #0

Transcript

Justin Florentine: Good morning, Knicks!

Nixo: Morning, Justin, how's it going?

Justin Florentine: It's alright. There's a lot going on. As usual.

Nixo: No December for you, though, huh?

Justin Florentine: Sadly, no. I just got back from a team offsite in Portugal, like, right before East Denver hit. I was… A little too wiped out to go straight from one event to another.

Nixo: Makes sense.

Justin Florentine: How's the turnout there?

Nixo: I haven't gone yet.

Justin Florentine: Is this gonna get recorded and end up on YouTube?

Nixo: Yes, it will.

Justin Florentine: God. Thank you, Nex.

Jannik Luhn: No.

Justin Florentine: Hey, Annik. Probably get started shortly. Give people some time to filter in, since this is our first call. We are being recorded, just FYI. We are gonna ask the… AI to summarize the meeting, and the recording will be posted on YouTube. Hey, Fabio Handers.

Fabio Di Fabio: Hi, everyone.

Justin Florentine: Take another minute to let people fill in, and then we'll get started. Let's see, let's post the agenda. The agenda is a little bit… Light, because it's our first meeting. I'm gonna post it in the chat… Cool. So, hey everybody, welcome to Encrypt the Mempool call number 0. This is a kickoff call. We're going to encrypt the mempool. The question is how and when. So… I think for starters… Everybody here should already be well-versed in the designs, understand them. This is really more of a project management call. does this time work for most people? Is this a recurring pain point for anybody? I think as long as we… we definitely need to have somebody from the 8105 folks, we definitely need to have somebody from the Lucid…

On each call, I think, until we, you know, stabilize those two EIPs. Yannick, this sounds good to you? Okay, good. I'm gonna make this work for me. At the very least… Okay. Good. So I think for starters, maybe we can, I think, really, as we get started, we really want to have all eyes on stabilizing these EIPs. It's the major first step that we need to hit. 8105 already has its EIP. Yannick, have you had changes, updates, new and interesting things that have happened on your EIP in the last week or so?

Jannik Luhn: Yes, we had. First of all, thanks for organizing the call, I think that's a great, great initiative, and… good to have, like, a regular space, to, to discuss this. For EIP, the update was, mostly what we've discussed earlier, the… switch to a more explicit two-slot execution design. We do that by having now two transaction types, one encrypted and one decrypted. The encrypted transaction goes to the first block, and then corresponding… correspondingly, the decrypted transaction at the start of the next block. So that should be, should make it easier for, I think applications to implement this, because there's not less, like, cross, information that needs to be Retrieve from a previous block for execution. What we have not changed there is that the…

Execution context for transaction will still be the previous block, so the decrypted transaction will… if it tries to access, for example, the Coinbase address or the slot number, it will still refer to the previous block. This is so that the next builder cannot communicate with transactions after they've been included. Yes, and one more thing we added there for the decrypted transaction that might be interesting for other proposals as well, I'm not sure, is that we added a reference to the envelope signer. So, basically, the decrypt transaction has to reference the encrypted transaction as a whole. This is so that, to prevent what we call an envelope stripping attack, imagine that the transaction gets included, and the key gets published, but the key is published late, so it does not get executed.

But then everyone can decrypt the transaction and potentially resend it again, and then front-run it. And to prevent that, we require the transaction to at least reference the sign of the envelope, so that only this entity can do this attack. And if they trust them, then this is prevented. So, yeah, I think these are the most important changes that we made to the proposal.

Justin Florentine: And these are all merged into… The EIP repository?

Jannik Luhn: They are pushed to the EIP repository, I'm not sure if they're merged yet.

Justin Florentine: I see, okay, I didn't see any open PRs… for them. Wait.

Jannik Luhn: Oh my god. I'm willing and send it to the chat.

Justin Florentine: That'd be great, that'd be great, thank you. Those are some significant changes, that's good. I think we're gonna wanna review those and take a look at them. Okay, any questions for Yannick? EIP-8105. Remind me, Yannick, how, gas is reserved between the two slots, now that you have a two-slot design.

Jannik Luhn: Yes, so that's also… by the way, I just looked it up, the PR has been merged, yesterday, including the new change.

Justin Florentine: It does have the new change. Great.

Jannik Luhn: Oh, sorry. Regarding gas, so we opted for basically making the encrypted transaction consume oil gas, and the decrypted transaction to consume no gas. And the idea there is that, The builder cannot sell block space of the next block. But we still want to preserve, kind of, the… on average, the block gas limit. So this, makes it possible for one block to use, more computation than is accounted for in gas, because if a decrypted transaction takes a long time to execute, then this… the transaction in which the decrypt… the block in which the decrypted transaction is included can… still has the normal amount of gas available. But this is only possible if the previous block was lighter in a way. So the block that included the encrypted transaction will have less computation while still paying for all the gas.

Justin Florentine: Okay. So this is… I think this is an interesting issue that both designs need to address, is that you are paying in block N for gas consumed in block N plus 1, and the base fee is likely going to change between them. And so, in block N, we charge them the full limit. I assume you guys at 8105 would charge the full limit. Specified on the encrypted transaction, is that right?

Jannik Luhn: Yes.

Justin Florentine: Okay. And… I assume that it's bound to the decrypted transaction having the same gas limit, and so now the question becomes, like, okay, well… Oh, what price do we charge them? Because… We're… we're… we're giving them a future, essentially, on the gas. That they're going to use in the next block, right?

Jannik Luhn: Yes, yeah, true. So that would be, in our case, the gas price of block N, the inclusion block.

Justin Florentine: Right. Had anybody considered this, or have any suggestions on… on approaches? You know, we could do things like just give it, like, a fixed markup. Where we say, if you're going to reserve the next block's gas, it's gonna be, you know, 10% more, 12% more, or something like that. We could… Calculate it, since we should know what the base fee will move to. In the block. We could charge it that way. It will complicate… gas metering, and EL clients. And, let's see, another way that we could do it would be, like, well, a fixed overhead, right? Where we say, like, this gas costs… X more… Where X is going to be greater than the possible change in the base fee.

And we say that that's just the cost of using the feature. And then the question is, is like, okay, do you burn the difference, I would assume? It burns the same way. The execution gas does. So…

Jannik Luhn: Do we know if this is valuable? Like, would people actually want to pay more for future gas, or is it, I mean, on average, I would guess it will cancel out, because, like, gas price will rise and fall randomly. So maybe we can just, if that's, like, not abusable, or not likely to be abused, maybe for simplicity, we can just, Use the, the, yeah, inclusion gas price.

Anders Elowsson: Yeah, so, actually, the thing is that, It's not random in a way, because the builder will know how much gas it uses, so the builder will know how much the price in the next block is going to be. For the transactions. But the thing is that the builder decides who gets in and who gets out. And so there's, like, no reason why, for example, if they're very… if the block is full, then… then the… the transaction that goes in in block N would benefit from the, paying for… in block N instead of block N plus 1. But… but the thing is that, it's sort of, The builder can always include a regular… it's not like an incentive to push your regular transaction into sealed transactions to pay less, in a way, because the builder can always…

Put in your regular transaction anyway in the block. So there's not super dangerous incentives, as far as I can tell, if you're short for block N. the base fee at plugin.

Jannik Luhn: Interesting, so it's basically, the builder could, yep. Basically, yeah, the question is how much gas will be used for encrypted transactions or serial transactions, and how much for regular transactions. And, you know.

Anders Elowsson: Yeah, so we have a… in this design, we have a limit for how much gas you can… Occupy top of block of the next block. So we… in the research post, it was a quarter, one-fourth, but now in the AP, it's currently specified to 1 eighth.

Jannik Luhn: Are there similar questions for pure fossil as well? Because that's always a bit strange for me, that. Basically, you can force a… yeah, you don't pay the includeers in this case, so you can get transactions in even if the builder doesn't want to, so you're kind of selling the builder's block space, I don't know, it seems to me that there might… Potentially be similar questions?

Anders Elowsson: Yeah, in fossil, you are not restricted in terms of gas, because it's a conditional design, and what this means is that you can have a fossil transaction that takes up all the gas, because you can make some sort of weird transaction where you just loop-loop over a for loop and write state, for example. But the thing is that you are limited in terms of the size of the transactions, and if you aggregate the sizes of the transactions that can be included via inclusion list, you are still limited to around… 16 times 8 kilobytes. But anyway, the builder will know, at the time it bids for the block, it will know how much, how much…

Justin Florentine: How much limiting?

Anders Elowsson: This… how much they are limited. So if they are very limited, then they will not bid so much, maybe, maybe.

Jannik Luhn: Okay. Yeah, I guess adding a limit in 8.105 should also be, like, Relatively straightforward. We had a limit as well for… in… our, NOSIS chain implementation. But that was just for security, so that, in case there's some abuse happening, that we don't… Use the whole block space for that. Yeah, so I guess that's not really relevant.

Anders Elowsson: Yeah, so in the Lucid design, the limit fills another purpose, which is that we guarantee that once you are in a beacon block, you will get, Executed, even if the next payload is missing, but we then want to push two payloads in a row with the… With, sealed transactions. They're the ones from the missing, that were… that were committed to in the beacon block, and the ones for the previous one. And so, we at least need space for, for… For twice as many sealed transactions as the… That's the limit we set.

Justin Florentine: Okay. So it sounds like we still have a little bit of thinking to do on the motor?

Jannik Luhn: Yeah, we can, like, we're going to… Have another look at our proposal and see if we need to make updates there, and compare with Lucid.

Justin Florentine: Okay. Alright, any other, discussion points that folks would like to bring up? This is kind of the open questions for the floor, section of the meeting. Unless, Andrews, did you have anything that you wanted to say more broadly about Lucid with regard to status?

Anders Elowsson: Not really, we're… we're, we're, we're… We're working on the IP. I think it will take a few more days.

Justin Florentine: Yep.

Anders Elowsson: Do we get something up?

Justin Florentine: Agreed. Cool.

Jannik Luhn: I have maybe one, question. that I've been thinking about, basically, I'm wondering if people have, done this already? So, we could look into real-world data, we could look at existing blocks, and see… check out the transactions that went through private mempools. And then see if we shuffle them randomly, if they still use the same amount of gas and lead to roughly the same execution results. Because if that's not the case, then, that would be maybe a reason that people would not want to use an encrypted mempool, because they don't have, like, specific ordering guarantees. That would mean they want to use private mempools, because they get, like, better, execution quality, basically. Another, thing that we could check there is if,

I forgot, I had one, other reason for that. But basically, yeah, did people… do we know if some people did research there, check into, check out how existing… oh, yeah, yeah, basically, the, the key withholding in order to front-run attack. Basically, keep the order as is, add other… and try to simulate front-running attacks, Yeah, and see how much gas that would use, and how much profit it would yield. That would… At least far, it's interesting to see if the… because then we will know if the trust graph is required and helpful or not. So I'm wondering if people have looked into this already, or if, if not.

Justin Florentine: I have not, and I have not heard of anybody looking into that.

Jannik Luhn: Okay, because then I think it would… I'm not sure how much time we have for that, like, on our side, how much resources, but at least the first thing, just looking into out blocks and shuffling the transaction and see if the outcome is still similar, I think that's, like, relatively easy to do, so we might try that, and if we do that, we're going to… reported here, I guess.

Justin Florentine: Okay. Alright, so this is maybe a call to action for anybody that thinks that they could help with this, We would be looking for analysts or, maybe map searchers that are willing to help. To provide some data and run these simulations. So if everybody could kind of reach out to your personal networks to see if there's anybody that would be interested in helping, please send them ENXY. Yeah, it sounds like… Bundle detection is kind of what you're looking for, right? Because the trust graph of the release keys, or the key providers, rather, in 8105. May require those bundles to be preserved.

Jannik Luhn: I'm not sure… so the bundle detection, I think, would be interesting, just for, So if a transaction's in a bundle, then it probably requires a specific order with other transactions, and I think then this is just not viable for, Yeah, for the public encrypted mempool designs that we've been discussing so far. Because there you don't have… you don't express an order requirement there. But yeah, that would be, I guess, an interesting… like, if there are lots of these bundles, then it's potentially problematic.

Justin Florentine: We should… we should write this problem down and outline it maybe a little bit more clearly, give it a name. I kind of see what you're saying here, but I don't know that I could verbalize it correctly to somebody that could actually answer it.

Anders Elowsson: I guess.

Jannik Luhn: Like you mentioned that.

Anders Elowsson: Yeah, I can mention that, we, we discussed with, there was Dot Always from Flashbots, who had a comment on our headliner proposal. And we discussed the issue of, Of, of, of, they, they, they have this, this, This… this functionality where they… they do these, order flow auctions. And, he mentioned the requirement of being able to bundle transactions, and in a response there, I talk about the fact that you can do this bundling in a… in a non-guaranteed way, but you can do it in Lucid, because you set the top of block the same for all your transactions. Or with an increment of one way, and then you will be pretty much guaranteed that the transactions will be executed in this order that you specify.

But it's also possible to, to enshrine that An order from the same decor. Or as key provider in ATA1 certifying. Would be, would have the same… Yeah, but to have retained order.

Justin Florentine: To me, that feels like something that we could add on later. Do you… Do you concur with that? Do you see that as… Necessary for… a minimal design.

Anders Elowsson: No, I'm just saying that… no, you're saying that right now you even have it. You have it already right now in the minimum viable EUP, but it's not guaranteed. Because if you, by chance, set the same, exact same way, top of book fee as some other, then you don't have it.

Justin Florentine: You don't have a way to determine that, yeah, yeah. What I'm talking about is making it… deterministic.

Anders Elowsson: Exactly.

Justin Florentine: Okay. Okay, then let's… we'll… we'll research this bundle issue a little bit better for our next meeting. To discuss. We've got 5 minutes left, I want to be mindful of time. Anything else folks want to discuss? Anything folks think they're gonna wanna discuss at our next call? Possible agenda items. Okay. Then, sounds like we keep grinding on our EIPs.

Stay in touch on Telegram. And encrypt the mempool.

Jannik Luhn: For topics for next week, or next call in two weeks, I guess, are we going to have a GitHub issue, where we can post them if things come up?

Justin Florentine: Absolutely, I can open one, I can open one immediately.

Jannik Luhn: Perfect.

Justin Florentine: Alright, thanks everyone. See you on the internet.

Anders Elowsson: Thanks.

Kevaundray Wedderburn: Yeah.

Fabio Di Fabio: Right, bye.

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