Encrypt the Mempool Call #11

Transcript

Justin Florentine: Yo, I'm here.

EF Zoom Bot: Hey, hey.

Justin Florentine: You're not a Bot, you're Wolvie!

EF Zoom Bot: Today, you win this round. I think… host… Alright, you're the man now, dawg.

Justin Florentine: Alright, thank you, sir.

EF Zoom Bot: Happy trails.

Justin Florentine: Appreciate it. See you. All right.

Jannik Luhn: Hello?

Justin Florentine: Hey, Jannik.

Jannik Luhn: Worked on first try now, joining the room.

Justin Florentine: Amazing. We're… we are learning.

Jannik Luhn: Making progress, yeah.

Justin Florentine: I credit Marc for this. He's been… Very attentive to my complaints about the Zoom room. So, things are working much better now, thanks to him.

Jannik Luhn: Nice.

Justin Florentine: Give folks… hi, Marc. We'll give folks a few minutes to filter in… Don't have a ton on the agenda today. It's kind of a brainstorming session.

Jannik Luhn: I'm not sure if you noticed it, I just added it, I don't know, half an hour ago.

Justin Florentine: Perfect.

Jannik Luhn: I created a… PR to the EIP to add the whitelisting stuff.

Justin Florentine: Thank you.

Jannik Luhn: Talk about that.

Justin Florentine: Here, I'll post a link here in the Zoom chat so folks can start processing it. Hello, Loring.

Loring: Hello, hello.

Justin Florentine: And, yeah, it could be low turnout today, not sure. Everyone's very busy. As usual. Okay, so we can get started, I guess, it's 3 after, The area of focus today is really to kind of brainstorm what we concluded last session, which was… Maybe we should… Maybe we should use the ordering of top of block To enforce, or prioritize, rather, trustable key revealers. So, the underlying concept was that You know, if you have a track record of not revealing your key, then you don't get to go to the top of the queue. Right? You gotta go to the bottom of the top of block. This still allows you to front run anybody that's in the remainder of the block, but not people that use more trustworthy key providers.

So I think that's the core of the mechanic. And Jannik kind of rocks, and opened a PR into Lucid. Which details this. And I apologize, this is the first time I'm seeing this, so I actually have not read this, I'm kind of scanning it right now.

Jannik Luhn: Yeah, sorry about that. I posted it a bit on short notice. You posted the link in the chat as well.

Justin Florentine: Sir, never apologize for solving problems for us, okay?

Jannik Luhn: Yeah, but yeah, maybe I can give a quick overview, overview, if that's helpful. Yeah, as you said, basically this mechanism of, getting a priority list in, and, like, I think in the last call, we still… or I was at least still calling it whitelist. I think priority list fits better, because it's now… Yeah, just a priority in the block, and it's still managed by the validator set that votes for it on the execution layer. I think the PR, there's two… can basically split up into two groups, for people to review it. One is the voting contract itself, like, what happens on the… on the execution layer, and how the changes then propagate into the consensus layer and be turned into this priority list. And then the second part is how this priority list is then, yeah, interpreted or abided by the consensus layer and by the block ordering rules.

So, the second one is just in… the first part is just in addition to the, to Lucid, and the second part is changes to Lucid. That's why I'm a bit more comfortable with the first part, because that's, yeah, the second part was for me a bit more difficult to, to get my head around, and there might be more, issues with that. Yeah, basically the mechanism did not change too much, the contract did not change too much from what we discussed last time. The only thing I added is a queuing mechanism to basically decouple the changes that go into the contract, and what gets then executed on the consensus layer. To prevent, yeah, spamming the consensus layer and to limiting the amount of changes that need to be.

need to be executed on the consensus layer. And also, I added a fee mechanism to, yeah, to discourage spam as well. And both mechanisms are more or less copied from similar EIPs. They have similar problems, like, for example, I think the validator consolidation messages use something like that, and there are a couple of other proposals that use similar mechanisms. So that's basically the same idea there as well. And for the changes to Lucid. one big one is that key messages, I think, now have to be signed, so I added a signature. The reason is that in plain Lucid, it doesn't matter, like, as long as the key is valid, we are happy. But now, with the priority list.

You could impersonate a key publisher on the priority list, and just pretend your transaction, or the key came from one of them, and then get a… gonna place in that, yeah, priority part of the block. And that would be a problem. And to prevent that, we can either sign key messages, which I think is easiest. The other alternative would be to assign the tickets, but I think that's a bit more complicated from a… key publisher's perspective operationally, because they have to review the… or the transactions have to be routed through them, basically, whereas the key release is already what they have to do, so I think signing them is… Quite natural there. Okay. The other big change is that I removed the max preceding commitments, for now at least, because I didn't find a better way. I think it's quite difficult to combine that with the priority list mechanism. Both are kind of there to, yeah, to

to constrain the order of transactions in a block and combining both is a bit tricky. Okay. Yeah, I'm not sure if I should go… a bit more into detail there. Basically, Lucid has this recovery mechanism, so if a key publi- or if a- if a builder does not publish the payload, or does- publishes an- publishes an invalid payload, then in the next block, it will kind of… make sure that the transactions that were committed still get into the next block. And I extended this to… Also reorder the transactions in case the builder releases a A payload that is, yeah, that has the transactions ordered in the wrong way, that does not, fulfill the priority list ordering requirement.

Yeah, and basically to resolve this, they get reordered in this recovery mechanism step, and this is now difficult for, the… basically the key publishers, which want to ensure that the max preceding commitments are fulfilled would have to predict this reordering step, potentially. So they have to look at all the transactions in the block and potentially reorder them, but they can't actually do this at the moment, because the key publisher is not specified in the commitment itself. It's only in the ticket. So… Maybe there are other ways to resolve it, but for me, I think the easiest way was to just replace or remove this max preceding commitments mechanism, especially because I think now it's not really needed anymore, or at least not as crucial because we have this other ordering mechanism. But yeah, it would be interesting.

Justin Florentine: Yeah.

Jannik Luhn: Get feedback from Lucid authors.

Justin Florentine: I find this… aesthetically pleasing? I think max preceding commitments feels a little bit overloaded to me, and ambiguous, and what you're replacing with is a lot clearer and easier to follow.

Jannik Luhn: Yeah, I think so too, so… Yeah. I think that's the big changes, I'm not sure if there's too much else, But yeah, it would be really helpful for me to get feedback from, Yeah, you, Justin, or other authors of Lucid. One thing I did not have a look at yet is the engine API changes, which I think there is at least one necessary to, yeah, to make the, the… Priority list, to communicate the priority list, But the protocol itself, I think, is… should work like this, but would be interesting to know if there's issues with it, or if other… if things could be done better.

Justin Florentine: Okay. I'll make a note to pay particular attention to the Engine API changes, thank you. But yes, I will review this entire thing, hopefully today. I'll also try to get some of Ander's attention, at least, and maybe Julian. To take a look at it. I'm also going to add a commit to this. Jannik, I'm going to put you on the authors. List, if we end up pulling this in, because I think this is a pretty big contribution. If… if we proceed with this, it's gonna sort out the optionality issue. And I'm also gonna escalate this to Tama. He had, some concerns about optionality in general, and I want to make sure that this is addressing those.

Sorry, I'm just saying that out loud as action items for me.

Jannik Luhn: Cool, yeah, thank you, that's very helpful.

Justin Florentine: So, the… let's see here, the body of people that are voting on the priority list of key publishers. Is that going to be all attesters? A subset of attesters? How big of a body do we need to vote on whether or not keys were revealed correctly?

Jannik Luhn: Right now, in the proposal, it's just the set of all active validators, weighted by, effective balance.

Justin Florentine: Right.

Jannik Luhn: That might be overdoing it, maybe a smaller subset would also be good enough. But I'm not sure if that would actually make things easier. Oh.

Justin Florentine: Okay. Maybe I'll talk to some CL folks about that. I guess the contention would be… I think the first alternative that pops to mind would be limiting it to people that already have duties in the epoch. Like, maybe you don't need the entire validator set to vote on it, but everybody that is, you know… Umm. Attesting in the epoch could.

Jannik Luhn: Yeah, yeah, this might make sense. I think the main argument for that would be efficiency. Right, because, I mean, the validators don't vote continuously, they just, delegate to a. Basically, they only have to update it when they think that the key publisher set needs to be exchanged. So, I think the main argument for restricting the set is making the counting or the tallying of the vote more efficient. And that is like I tried to do it, try to, structure it in a way that you can compute it iteratively. The. The tally, so you don't have to recompute it whenever there's a change in the contract. But you still need to recompute it when the effective balances change, which is once per epoch.

And I don't think there's a way around that, because that's basically the voting weights. So if that turns out to be too, yeah, too computationally heavy, then it might make sense to restrict that. I did some preliminary benchmarks, and they look good to me, so I'm not sure if it's necessary. Oh. But yeah, something to consider. I don't think… I don't think the full validator set is, is strictly necessary for, to make it secure, so… Yeah, using just a subset would probably also be fine.

Justin Florentine: Okay. Well, it's an open floor. This is kind of it for the agenda for today, so… If folks want to review this PR, and… Ask questions, comments, concerns… Floor is yours. Oh, do we have a note on, like, testing the keys? I.e, like, if you want to assert that, like, hey, you didn't reveal the right key. Like, how do you know that that's the case? Or are we just saying you didn't reveal a key at all?

Jannik Luhn: I didn't look into this specifically, but that should already be handled by existing Lucid, right? Is there a difference? And we just… we reject keys that… we just have an additional rejection condition now, if the signature is invalid, but we still reject it if the key itself is invalid, which… I assume Lucid already does.

Justin Florentine: it… Does… but… I guess what we need to figure out is, like, how that reason gets back from the CL to… The priority list.

Jannik Luhn: Yeah. I mean, there's no automatic mechanism to kick out key publishers. At the moment, I'm not sure if that would be desirable. So they don't get automatically punished for revealing an invalid key.

Justin Florentine: That's a good question. Like, a habitual line stepper is gonna be, like, still at the top, or the bottom of the top of the block. They're still gonna be able to front-run the public pool.

Jannik Luhn: Yeah, it basically relies on the validator set to do their job and to vote them out.

Justin Florentine: I mean, that in itself should be a signal for people to stop using it, but I guess… How much do we trust that?

Jannik Luhn: Yeah, but this could probably be an external software, basically. A monitor that checks… And that validators are encouraged to run the checks which Key publishers do their job, and Vote them out if not. And that could also… kind of be a way to document a way for new key publishers to join? Because that's also something we discussed last week, that if you're a new key publisher, you can already start your job, you can already start working, just not in this priority section, and then make a name for yourself, and at some point be upgraded. And maybe this can, at least to some extent, be automated, and if the conditions of that are kind of defined by this.

Yeah, external, tool. That might be helpful. I guess it both goes both directions, it's what I'm saying.

Justin Florentine: Right, right, right. Right, permissionless entry to the key provider set.

Jannik Luhn: And there's another thing I, I want to mention is I said that max preceding commitments is gone, but the top-of-block fee is still there, and I basically left it there because it's… Yeah, this one doesn't clash with the new mechanism, but I also think it's maybe not as crucial to have it anymore. Because as long as you're in this priority section of the block, you don't really care where you are, and if you're not in the priority section, you have Yeah. Something's lost already, maybe. So that might also be something we could consider removing.

Justin Florentine: Hmm.

Jannik Luhn: Just to simplify it a little bit.

Justin Florentine: Are you talking about the top-of-block fee? Which fee are you talking about?

Jannik Luhn: Yes, the top-of-block fee.

Justin Florentine: Why is that… why is that safe to do? Because we do need to constrain that to a particular, fraction of the overall block size. And so if it's constrained, we kind of need some way to… Regulate who gets in and out of it, right?

Jannik Luhn: Okay, right, yeah, that's, that's true. It's not just about ordering, it's also just who gets in and who doesn't, if there's… congestion. Yeah, true. For that, we still need it. But I guess it doesn't… wouldn't have to be necessarily at top-of-block fee. Because once you're in, you don't care about the order anymore, that's, like.

Justin Florentine: Right. Yeah, and now you have two dimensions to potentially order by, right? I'm willing to pay X, and my key provider is trusted Y.

Jannik Luhn: Oh, okay, that is actually not done by… maybe, maybe that should be done by the proposal, The… as long as your, key publisher is prioritized, it doesn't matter if you're just barely in, or if you've got 100% of the votes.

Justin Florentine: Right…

Jannik Luhn: That might be interesting to still have, yeah, put the trusted… the most trusted key publishers in the front.

Justin Florentine: But, like, I don't know that we want MEV searchers competing on key trust. Like, they need another dimension to compete on, right? And I think that should be… I don't know, it should be… I like the existing mechanism for that, let me say.

Jannik Luhn: Yeah, yeah, true. That would be very strange if people tried to game that.

Justin Florentine: Right, right, you could get some weird collusion… Effects. Because you're grouping everybody by, like, oh, this is a really trusted key publisher. It's like, okay, well… everybody's using them. How does… how does the ordering get… get decided? Hmm.

Jannik Luhn: Yeah, okay, so maybe keeping the top-of-block fee probably makes… still makes sense.

Justin Florentine: I think it does, but now I don't know how to actually write an implementation that prioritizes the key publisher. I mean, you could spec it like there's a threshold. Like, anybody that has, you know, fewer than however many demerits on their key publishing. All get to participate in Top of Block equally.

Jannik Luhn: Yeah, this is basically how it works. I mean, The top-of-block fee is still used right now to order in this priority section of the block. And in that section, it doesn't matter which key publisher you used, as long as you used one of them that had… that's more than 50% support. Oh.

Justin Florentine: Okay.

Jannik Luhn: So they're not even ordered by a key publisher anymore. It can be key publisher A at the top of the block, then transaction from another key publisher B, and then key publisher A again.

Justin Florentine: Yeah, they can be interleaved, it's just a set of everybody that has met the trust threshold.

Jannik Luhn: Yeah, exactly.

Justin Florentine: Okay, good, good. That's fine, then. Then we just keep the… the fee. Okay, good. Okay. Hmm. What else we got here?

Jannik Luhn: There is a part which I don't like, syntactically too much, I didn't know how to do it properly, the key message signing, the format of that. Because it kind of combines. the normal RLP transaction signing with the… SSZ container signing, but none really fits, because the container is a, For container signing, we usually use BLS signatures, but for this we can't, because the key publishers are execution-layer addresses. Yeah, it's kind of mixing both, so I didn't… I wasn't sure which mechanism to use, so that's… There might be better ways to express this, or there definitely are better ways to express this.

Justin Florentine: So frame transactions lets us abstract this a little bit. There might be an opportunity to leverage that.

Jannik Luhn: Yes, but it's the key message, so it's not really a transaction.

Justin Florentine: Oh, right, right, right, right. I have. Yep, yep, yep.

Jannik Luhn: So it's basically a consensus-layer message that uses the execution-layer signing scheme.

Justin Florentine: Right. So, it's a potential interaction with frames, then. Like, if you had… if you had… if you were to treat the validation of The… Origin of the key… As a frame within the transaction. It would need to know how to interact with this key message to retrieve the actual key material, and how big it was, and what type it was.

Okay. Alright, we're at the 30-minute mark. Does anybody have anything else they want to go over? Because… I don't know that we need to all just read the PR together in silence. Going once. Going twice… Everybody wants 30 minutes back, okay. Cool. So, your homework tonight is to read this PR, provide, comments, reach out to folks with concerns, questions. Run it by your local CL dub, see what they think. And, have fun. Cool. I'm gonna wrap here.

Thanks, everybody. Talk to you soon. Jannik, great work, buddy. Thank you. Thanks for This is gonna be fun food for thought. I'm gonna enjoy chewing on this.

Jannik Luhn: Yeah, looking forward to hear from here your feedback.

Justin Florentine: Alright. Sounds good, everyone. See you next time.

Marc Harvey-Hill: Bye.

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