Encrypt the Mempool Call #1

Transcript

normad | pbsf: Hi, dear.

Luis Pinto: Good day.

Jannik Luhn: Hello?

Justin Florentine: Encrypting the mempool… Hi, everyone. Take a couple minutes for folks to arrive.

Jochem Brouwer: DM, DM.

Justin Florentine: Hey, Yakim.

Jochem Brouwer: Ayy.

Luis Bezzenberger: Oh.

Justin Florentine: Luis… Ben, what's good, buddy?

Ben Adams: Ayy.

Justin Florentine: Admin, that's impressive. How do I get root access?

admin: I'm not logged in. This is Loring from Shutter.

Justin Florentine: Okay, Lori. Alright… Nice, nice, nice. Let's see… Let's see, let's see, let's post the agenda here so folks can get to it. Oh, which I… closed. I don't know. Why would I do that? This is meeting number 1, because we already have meeting 0. Agenda is here in the chat. Thanks for joining, y'all, we can get started, couple of things to discuss.

You probably heard already, EIP8105 has been withdrawn. This was the Universal Encrypted Enshrined Mempool design. It has been withdrawn, with the intent of improving LUCID to cover what it provides. So the authors felt that LUCID got them where they needed to go, and we've withdrawn that one, and we're pursuing with the LUCID design. Speaking of elusive design… There's an EIP that just got published this morning by our own Anders Ellison. Hi, Anders, welcome. That's… this is the link to the pull request for the EMS.

Anders Elowsson: Yeah, let me share the link.

Justin Florentine: Yes, sir. You got it. I just put it in the chat. So this will, you know, it will look a little bit different than the ETH research post, because this is more of an engineering document, you're all familiar with EIPs, so you're gonna have a lot more specifics in here. Further discussion should be directed to the pull request, or asynchronously, you know. But if you have… Ideas for improvements to it. Please, they are welcome. Okay, with that, I think we kind of open up the floor here. To questions, comments, and concerns. I think one of the things that I wanted to talk about was… And maybe we… we don't have to start with this one if there's something else folks would rather start with, but beacon chain RPC APIs?

the design as it stands right now needs to kind of be able to listen for events on the beacon chain and, send messages to the beacon chain from the wallet, and that's kind of a new thing. So… who has thoughts on that? I know RPC providers do provide the beacon chain RPCs? So they're out there, they're usable. But, what do folks think about that? Correct, Yakim. 8105 is being withdrawn. And LUCID is… Going to take its place. No thoughts on beacon chain RPCs? I'm not a CL developer, but I was fine with it.

Okay.

Jannik Luhn: Is there… is there a lot to, to discuss there? I guess if we need new endpoints, then I guess we have to add them. The fact that there's now an EL and a CL API that has to be used from wallets, it's kind of… Annoying, but it is what it is.

Justin Florentine: So.

Ben Adams: I mean, that's… Optional, is that correct? You don't have… not everything is necessarily forced to be encrypted.

Justin Florentine: Correct, oh yes, correct. This entire feature is optional, that's correct. So it would be an update to an existing RPC method and the addition of a new one. Okay, so there'd be a new one for actually releasing the key, and then a new event type to listen for. So the BeaconChain RPC API already has, like, a WebSocket-type thing where you can listen for events with filter. This would be adding support for, hey, your transaction has been included, you are safe to reveal the key. So, new, new event. You can find this in the section called Beacon Chain RPC API Changes in EIP. Bukaz is asking for a 5-minute pitch of LUCID and another 5 minutes for its biggest issues and pitfalls. I can see CLRPC as a definitive nuisance. Would you mind saying more as definitive nuisance?

Łukasz Rozmej: Well, it's something that it's… you said it's not specified yet, so something that we would have to go and do, right? Just for it?

Justin Florentine: I mean, the overall beacon API is specified, is that what… is that what you're referring to?

Łukasz Rozmej: No, sorry, sorry, I had to misunderstood something then.

Justin Florentine: Okay, yeah, it would be one new method that needs to be specified and updates to an existing method. Okay.

Jochem Brouwer: Yeah, maybe, maybe to ask, because this PR dropped 40 minutes ago,

Justin Florentine: Yeah.

Jochem Brouwer: And Lucas is also saying, like, yeah, can we have, like, a pitch of this, and maybe also, like, some, changes, because, yeah, I… could not beat the PR in 1 minute or 40 minutes, yeah.

Justin Florentine: Sure. Sure. So, Anders, would you like to do this one, or do you want me to go for it? You're on mute. Okay. Well, Anders… I guess I'll go. So, yeah. The pitch for LUCID essentially is a two-slot design. where… Users reveal their ticket, essentially, that claims a portion of the block space. Where they say, alright, I'm gonna be sending a transaction, it's currently encrypted, and… Here's my ticket that kind of reserves it in the next block.

Right? So you can look at this as not really all that encrypted, it's like a little encrypted for a slot. So that way that the transactions can be populated across the meth pool, they can't really be inspected, they can't be acted on, and then once the transaction is included via its tickets. The wallets will then reveal their keys. Keys will be used by the builders to decrypt and build their block in the order that they paid for, with their top of block fee. so that's kind of the high-level elevator pitch. As far as pitfalls, I think, You know, it prevents… it only prevents front running. It really is, is, like I said, it's more of a transaction ordering fix.

So you could look at that as a pitfall. There's currently a debate ongoing right now in the encrypted Mempool's, Discord channel on R&D as to how it impacts back running. Like, if we consider back running to be good MEV, this may make it less efficient. Because what you would be backgrounding would essentially be the entire top of block. Like, you wouldn't actually be able to insert transactions in the, into the encrypted. The LUCID block space, if we think of it as its own block space. is inviolable, right? Those are already ordered, so even if they are revealed in plain text, you can't insert stuff in there. You can only backrun the result of the entire top of block.

What are some other pitfalls and shortcomings, The… Folks think should be brought. to light. Anders, Julian, anything you want to add? Yes, this one slot delay is considered… your prices are gonna be stale, right? Ish. So you had a non-deterministic timing in slot N, and now you're gonna go to… slot N plus 1. And you're gonna be behind based on your top-of-block fee. So if you don't bid the highest top-of-block fee, everybody else that did outbid you is gonna go in front of you. So, yes, there's… your prices will decay a little bit. any overhead on the network side. With regard to bandwidth increases, there's new traffic, it's small traffic, the keys are small, the tickets are small, but it would be new traffic and, some potentially new topics on the CLP2P network.

If the encryption key is not revealed, Anders, correct me if I'm wrong here, but…

Anders Elowsson: I can talk about it a little, yeah.

Justin Florentine: Okay, great.

Anders Elowsson: do not reveal your encryption key. We have, in this latest version, instituted a penalty. So what happens is that, when you pay for the encrypted transaction, you pay a top-of-block fee to be… and the commitment that pays the highest top-of-block fee goes the first. And if you, decrypt your transaction. Such that you, you, you reveal, the transactions that matches the, the, the commitment in the ticket. Then, you are returned a proportion of this top-of-loc fee. And currently, it's set so that you are returned 63 out of 64. So it's like you are returning 98% of what you paid, or something like this, for, for actually decrypting. And if you do not decrypt, then, you lose out on that,

Top of lock fee that you paid. You can set the topography to zero, such that you do not have to pay any penalty for not revealing, but then you will end up lost, within the top of the block. And you may not be included also, because if someone else pays higher, then… Yeah, they would probably go before you.

Justin Florentine: Thank you, Anders.

Anders Elowsson: And I can mention one thing more, is that if you do not reveal, you also, the, the… There's nothing… like, there's… you don't… we don't waste the block space, because, then the builder of the next block simply ignores that… And so it doesn't count against the Gauss limit of the look.

Justin Florentine: Maybe this would be a good time… Andrews, could you elaborate on how we know a key was not revealed? I think that might be a mechanic that folks could, learn a lot from.

Anders Elowsson: How we know a case? Well, so the current implementation has a PTC vote. On which cases that are available. And, these PTC votes are, absurd, and, And the builder must adhere to whether the PTC voted that the keys were revealed or not. And so, you know if a key was revealed, if the decryptor address that was specified in the ticket released a key. That, that decrypted the transaction such that you get, something that matches, the, the reveal commitment in the, in the ticket.

Justin Florentine: Thank you. Mark has a question in the chat. If we do this in Hegota and we also do frames, how do the proposals interact? You know, we haven't really looked into that too deeply, because having 3 headliners and a hard fork would be a little wild. You know, Hegota is kind of… either Frames or LUCID or SC. Do encrypted transactions go into Frames? .

Anders Elowsson: I can mention one thing. I cannot answer that question either, because I haven't looked into it, but I can talk about the interaction with FOCIL. So, the currently… the current specification is that we should, interact with FOCILs such that the inclusion list should be able to include, these, sealed transactions. But this is not a requirement, because you get quite a lot of censorship resistance, even without having this. This is something that can be added later, because… even without adding it so that you put the transactions into the inclusion list, you still have this property that the sender is hidden, and the content is hidden. So, like. A lot of the rationale for censoring a transaction isn't there anymore.

Justin Florentine: Great.

Mark Holt: Well, that depends how long the transaction sits in the transaction pool, actually. Because you're thinking about, censorship, but there's also non-disclosure. Right, because you might want… A non-censored transaction that's actually going to be quite long-lived in the transaction pool?

Anders Elowsson: I don't understand the question.

Mark Holt: Whoa. I think the thing is, you end up needing both. Right, because I think what encryption is doing is protecting you from the… Inclusion order issue, but also the information leakage issue. And the information leakage issue is actually around the mempool, not, you know, not the block building.

Anders Elowsson: Yeah, but why would… so my point would be like this, why do someone censor a transaction? Perhaps because it acts as a contract that you don't want to access, or it does something that you don't like, or something like this? But in the case that you don't know anything about what the transaction is gonna do, it's very hard to find an economic rationale for censoring just a random transaction from a new account. And the only reason you will have for actually census… like, the only mechanism for censorship in this case that is reasonable is If you, for example… you cannot blacklist one address, because you can hide this under… But you can do some sort of whitelisting where, okay, I am, as a builder, only accepting transactions from these addresses. But in this case, it's very difficult to be profitable as a builder, so we would presume that this would not happen, and so we uphold censorship even…

Quite strongly, even without going and using FOCIL.

Luis Bezzenberger: By the way, that's also why in EIP8105, there was… That was not the case that it went through via FOCIL, but rather just be a normal transaction type. So I just want to underline that point.

Anders Elowsson: Alright, cool.

Justin Florentine: Alright. We've got about 10 minutes left. I'm happy to entertain more questions from the floor, if there are any. Everybody's probably reading the EIP. Is anybody here, representing builders? Or searchers? I'd love to hear some input from… From folks that, coming at it from that perspective. Okay?

I have on the agenda to talk about bundling. And ciphertext encapsulation. Cipherdex encapsulation is kind of a new thing, that we're adding. We're actually suggesting some symmetric encryption that should be used for the encrypted transaction. And, you know, that's… that's a new thing. It's gonna use AEAD, as described in RFC 9180. Which is a somewhat standardized ciphertext encapsulation format, so we'll have, you know, suggestions on how to structure the data, and how it should be used. There is also, however. header bytes, and extension capabilities. So… While our suggestions right now are using, symmetric… Cryptography in envelopes.

That are, that are defined. There's nothing that prevents us from extending or creating entirely new ciphertext encapsulations. I know that's a major concern for all of us as we look at our post-quantum future. And so, with that regard, the encryption there is abstract. Okay. And then last thing is the notion of bundling. Anders, where did we leave off on bundling with this, fi- not final, but… most recent draft of the EIP.

Anders Elowsson: Yeah, so we include bundling, because, yeah, it felt like it was an important feature to have, so you can bundle, many different, The decryptor can bundle many different, Of these, sealed transactions into one, one singular commitment. And, this is useful because… for various reasons. One reason is that you… Yeah, so you release just one key message for all the… the transactions, and you can do two different ways. You can release the key message for bundles. You can either release one key for each transaction to be included, or one key for all the transactions in the bundle. Depending on your encryption scheme. If you're a threshold encryption, for example, you will use one key. And target the specific slot for your transaction slightly.

Justin Florentine: Let's see. Lucas likes the explosion of transaction types. Do you have any ideas on how to avoid it?

Łukasz Rozmej: So, one idea is probably frame transactions. Our idea is, kind of wrapping transactions with adding them, adding to them some kind of additional, functionality, right? So, one transaction type wraps the another and adds some functionality to it, right? Those are two things that come to my mind. Because, you know.

Justin Florentine: Can you elaborate on why you dislike the explosion of transaction types? By my account, we're up to, like, 5.

Łukasz Rozmej: Okay, because we're… we're going in a way, I already, I think, mentioned it on ACDC, we're going in a way that we have… It's like an inheritance hierarchy. Right? So if we want to… add some new transaction with some new functionality, and it needs to be encrypted, you know? Now we cannot kind of… how do we do that, right? In some way, and we add more and more and more and more and more. Instead of, for example, we could do composition.

Justin Florentine: Oh, this is… these are composed. You can stick any type of transaction inside this encryption envelope.

Łukasz Rozmej: Envelope signer, non… well, no, that's any…

Justin Florentine: Sounds like blob transactions. Yeah… Are we allowing decrypted and encrypted transactions at the same time? Yep, we sure are, and it does make sense because we want it to be an optional feature that folks use.

Luis Pinto: But, would that not make, like, a way of escaping this feature? You know, in a sense. Like, like, people… Could… could maybe, like, censor private transactions going forward, and only run the normal ones.

Justin Florentine: So, Fossil protects against that. That's kind of why we refer to, like, the Holy Trinity of… privacy features for Ethereum, right? Proposer-builder separation, FOCIL, encrypting the mempool. They all kind of lean on each other and provide different, different aspects in one happy little system.

Mark Holt: Yeah, it seems likely that you need all three, because in practice, if you're a regulated builder. You might well end up having a regulator saying, don't include… You know, this encryption and privacy thing is like a big red flag. Which is why I think if you're gonna do this, you end up needing Fossil. Which is not… it's not a technical thing, it's a… it's a legal thing, right?

Luis Pinto: What… what are the disadvantages of making everything encrypted from day one?

Justin Florentine: So, right, so we reserve, I think it's 1 eighth of the block space, for LUCID types of transactions. And Anders, stop me if you'd prefer to speak to this. But… You know, if you allowed the entire block to be… encrypted, you kind of take us back to the bad old days of priority gas auctions. Right? Like… You, you…

Anders Elowsson: There's one specific reason why we never want to make more than half of the block in these transaction types, and it's because we want to be able to… in the case that the payload is not revealed, we want to catch up. And that's why we want to allow twice as many transactions in the next payload. So we want to have our cap at half the SCs.

Justin Florentine: Right, and that's for payload withholding, not necessarily key withholding. Got it. Okay. Well, we're at. Why is there a reserve space rather than some kind of gas auction mechanism? I mean, I didn't explore that design space, did you, Anders? Hmm. Happy to, yeah, happy to pers- to follow up.

async, Lucas, with that. I just want to be mindful of people's time. I believe we're at time. We only had a… Oh, no, we have an hour. My bad. My bad. So does that answer your question, Lukaz? Andrew's response in chat? Aye.

Łukasz Rozmej: I have a… Additional question. If I… not sure if I understood it correctly. Post it in the chat.

Justin Florentine: Okay.

Anders Elowsson: I don't quite understand your question in the shop. You have to…

Łukasz Rozmej: Okay, so what does it mean that you have reserved? What does it mean? One ice.

Anders Elowsson: Maybe I said it wrong sometime, or some… was it this reserved? I think it's probably not what we want to frame it as. What we can say is that it's the maximum, so you can use the maximum, 1 eighth of the block's gas for this. Sealed transactions in the first, and expanded up to half.

Łukasz Rozmej: And if there are more of those transactions, then part of them are ignored? What happened?

Justin Florentine: They'd just be delayed till subsequent blocks?

Anders Elowsson: It's just the same as always. It's the same as… if now there are more than twice. If there are now more than the block fits, it's just the same again. It doesn't change.

Łukasz Rozmej: Okay, but even if they pay more than the other transactions that fit into the block, they still will have to wait because of that limit.

Anders Elowsson: Yeah, unless there are… I mean, you have, you have the inclusion lists as well that factor into this decision, but yeah, if, if… If you fill the block. And the biller is free to decide, then the builder is free to decide if they want to include them or not.

Mark Holt: So where did you get to the one…

Anders Elowsson: Sorry, where did you go?

Mark Holt: Yeah. Where did you get to the 1A?

Anders Elowsson: I frame it a little bit weird, because, Because… I shouldn't say it like that, because when you are a builder, you have already So, so we set the setting was 18. So when you are a builder, you have the committed transactions to your block already, and so it can be at most of this one-eighth of these transactions that you have to include, which are these sealed transactions that have now been encrypted and will be executed first on top of your block. And so those are given upfront. And then you have 7-8 of the book for your own transactions. And you also commit to tickets for the next book. But those 1-8 have already been paid for beforehand.

Justin Florentine: Do we have a block validity rule that checks for that? That would be kind of… Probably something that we should add, yeah? Like, you know what the block limit's… you know what the gas limit's gonna be in the next block. And so, you should probably not try to include more tickets in the N-1 block than you're gonna have room for in 1 8th of the next block, yeah?

Anders Elowsson: Yeah, so you can at most include 1 eighth. Of… you can at most include tickets that pay for and consume 1 eighth of the gas of the next block.

Justin Florentine: Okay. Okay, well, we got time to kill. If folks, have more questions, throw them on out there. If not, we are at the end of the agenda. Alright, sounds like… It's time to wrap it. Thanks everybody, you can find us on Discord and the R&D channel in the encrypted mempools. Subchannel? Please keep the conversation going, please reach out to any friends that you have in the MEV ecosphere, right? If you know builders, you know searchers, we'd love to get their opinions on some of this stuff to try and figure out, you know, other perspectives that we can look at the problem from.

So thanks, everyone, as always. And wallets, too, yes, 100%, please. Wats need to use this. So we need to make sure that we are hearing them. Brad, feel free to reach out to me, Julian, or Anders. With any… any concerns? Thanks, everyone.

Julian: And do you adjusted.

Justin Florentine: You got…

Mark Holt: Okay, thanks.

Luis Bezzenberger: Thank you.

Jannik Luhn: Thank you, bye-bye.

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