Justin Florentine (Besu):Take another minute to let people fill in, and then we'll get started.
Transcript
Justin Florentine (Besu):Let's see, let's post the agenda. The agenda is a little bit…
Justin Florentine (Besu):Light, because it's our first meeting.
Justin Florentine (Besu):I'm gonna post it in the chat…
Justin Florentine (Besu):Cool. So, hey everybody, welcome to Encrypt the Mempool call number 0.
Justin Florentine (Besu):This is a kickoff call. We're going to encrypt the mempool. The question is how and when.
Justin Florentine (Besu):So… I think for starters…
Justin Florentine (Besu):Everybody here should already be well-versed in the designs, understand them. This is really more of a project management call.
Justin Florentine (Besu):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…
Justin Florentine (Besu):On each call, I think, until we, you know, stabilize those two EIPs.
Justin Florentine (Besu):Yannick, this sounds good to you? Okay, good.
Justin Florentine (Besu):I'm gonna make this work for me.
Justin Florentine (Besu):At the very least… Okay.
Justin Florentine (Besu):Good.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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…
Jannik Luhn:good to have, like, a regular space, to, to discuss this. For EIP, the update was, mostly what we've discussed earlier, the…
Jannik Luhn: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.
Jannik Luhn: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
Jannik Luhn:Retrieve from a previous block for execution.
Jannik Luhn:What we have not changed there is that the…
Jannik Luhn: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.
Jannik Luhn: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.
Jannik Luhn: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.
Jannik Luhn: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.
Jannik Luhn: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 (Besu):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 (Besu):I see, okay, I didn't see any open PRs… for them.
Justin Florentine (Besu):Wait.
Jannik Luhn:Oh my god.
Jannik Luhn:I'm willing and send it to the chat.
Justin Florentine (Besu):That'd be great, that'd be great, thank you.
Justin Florentine (Besu):Those are some significant changes, that's good.
Justin Florentine (Besu):I think we're gonna wanna review those and take a look at them.
Justin Florentine (Besu):Okay, any questions for Yannick?
Justin Florentine (Besu):EIP-8105.
Justin Florentine (Besu):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 (Besu):It does have the new change. Great.
Jannik Luhn:Oh, sorry.
Jannik Luhn: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,
Jannik Luhn:The builder cannot sell block space of the next block.
Jannik Luhn:But we still want to preserve, kind of, the… on average, the block gas limit. So this,
Jannik Luhn: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.
Jannik Luhn: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 (Besu):Okay.
Justin Florentine (Besu):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.
Justin Florentine (Besu):And so, in block N, we charge them the full limit. I assume you guys at 8105 would charge the full limit.
Justin Florentine (Besu):Specified on the encrypted transaction, is that right?
Jannik Luhn:Yes.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):And…
Justin Florentine (Besu):I assume that it's bound to the decrypted transaction having the same gas limit, and so now the question becomes, like, okay, well…
Justin Florentine (Besu):Oh, what price do we charge them?
Justin Florentine (Besu):Because… We're… we're… we're giving them a future, essentially, on the gas.
Justin Florentine (Besu):That they're going to use in the next block, right?
Jannik Luhn:Yes, yeah, true.
Jannik Luhn:So that would be, in our case, the gas price of block N, the inclusion block.
Justin Florentine (Besu):Right.
Justin Florentine (Besu):Had anybody considered this, or have any suggestions on… on approaches?
Justin Florentine (Besu):You know, we could do things like just give it, like, a fixed markup.
Justin Florentine (Besu):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.
Justin Florentine (Besu):We could… Calculate it, since we should know what the base fee will move to.
Justin Florentine (Besu):In the block.
Justin Florentine (Besu):We could charge it that way.
Justin Florentine (Besu):It will complicate… gas metering, and EL clients.
Justin Florentine (Besu):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…
Justin Florentine (Besu):X more… Where X is going to be greater than the possible change in the base fee.
Justin Florentine (Besu):And we say that that's just the cost of using the feature.
Justin Florentine (Besu):And then the question is, is like, okay, do you burn the difference, I would assume?
Justin Florentine (Besu):It burns the same way.
Justin Florentine (Besu):The execution gas does.
Justin Florentine (Besu):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.
Jannik Luhn:So maybe we can just, if that's, like, not abusable, or not likely to be abused, maybe for simplicity, we can just,
Jannik Luhn:Use the, the, yeah, inclusion gas price.
Anders Elowsson:Yeah, so, actually, the thing is that,
Anders Elowsson: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.
Anders Elowsson:For the transactions. But the thing is that the builder decides who gets in and who gets out.
Anders Elowsson:And so there's, like, no reason why, for example, if they're very…
Anders Elowsson:if the block is full, then… then the… the transaction that goes in in block N would benefit from the,
Anders Elowsson:paying for… in block N instead of block N plus 1. But… but the thing is that, it's sort of,
Anders Elowsson: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…
Anders Elowsson:Put in your regular transaction anyway in the block.
Anders Elowsson:So there's not super dangerous incentives, as far as I can tell, if you're short for block N.
Anders Elowsson:the base fee at plugin.
Jannik Luhn:Interesting, so it's basically, the builder could, yep.
Jannik Luhn:Basically, yeah, the question is how much gas will be used for encrypted transactions or serial transactions, and how much for regular transactions.
Jannik Luhn:And, you know.
Anders Elowsson:Yeah, so we have a… in this design, we have a limit for how much gas you can…
Anders Elowsson:Occupy top of block of the next block.
Anders Elowsson: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.
Jannik Luhn: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,
Jannik Luhn: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.
Anders Elowsson: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…
Anders Elowsson:16 times 8 kilobytes.
Anders Elowsson:But anyway, the builder will know, at the time it bids for the block, it will know how much, how much…
Justin Florentine (Besu):How much limiting?
Anders Elowsson:This… how much they are limited.
Anders Elowsson:So if they are very limited, then they will not bid so much, maybe, maybe.
Jannik Luhn:Okay.
Jannik Luhn:Yeah, I guess adding a limit in 8.105 should also be, like, Relatively straightforward.
Jannik Luhn:We had a limit as well for… in… our, NOSIS chain implementation.
Jannik Luhn:But that was just for security, so that, in case there's some abuse happening, that we don't…
Jannik Luhn:Use the whole block space for that.
Jannik Luhn: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,
Anders Elowsson:Executed, even if the next payload is missing, but we then want to push two payloads in a row with the…
Anders Elowsson: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.
Anders Elowsson:And so, we at least need space for, for…
Anders Elowsson:For twice as many sealed transactions as the… That's the limit we set.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):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…
Jannik Luhn:Have another look at our proposal and see if we need to make updates there, and compare with Lucid.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):Alright, any other, discussion points that folks would like to bring up?
Justin Florentine (Besu):This is kind of the open questions for the floor, section of the meeting.
Justin Florentine (Besu):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…
Anders Elowsson:We're working on the IP. I think it will take a few more days.
Justin Florentine (Besu):Yep.
Anders Elowsson:Do we get something up?
Justin Florentine (Besu):Agreed. Cool.
Jannik Luhn:I have maybe one, question.
Jannik Luhn:that I've been thinking about, basically, I'm wondering if people have, done this already?
Jannik Luhn: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.
Jannik Luhn: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.
Jannik Luhn: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.
Jannik Luhn:Another, thing that we could check there is if,
Jannik Luhn:I forgot, I had one, other reason for that.
Jannik Luhn: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,
Jannik Luhn:Yeah, and see how much gas that would use, and how much profit it would yield.
Jannik Luhn:That would…
Jannik Luhn: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.
Jannik Luhn:So I'm wondering if people have looked into this already, or if, if not.
Justin Florentine (Besu):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…
Jannik Luhn:reported here, I guess.
Justin Florentine (Besu):Okay. Alright, so this is maybe a call to action for anybody that thinks that they could help with this,
Justin Florentine (Besu):We would be looking for analysts or, maybe map searchers that are willing to help.
Justin Florentine (Besu):To provide some data and run these simulations.
Justin Florentine (Besu):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.
Justin Florentine (Besu):Yeah, it sounds like… Bundle detection is kind of what you're looking for, right?
Justin Florentine (Besu):Because the trust graph of the release
Justin Florentine (Besu):keys, or the key providers, rather, in 8105.
Justin Florentine (Besu):May require those bundles to be preserved.
Jannik Luhn:I'm not sure… so the bundle detection, I think, would be interesting, just for,
Jannik Luhn: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,
Jannik Luhn:Yeah, for the public encrypted mempool designs that we've been discussing so far.
Jannik Luhn:Because there you don't have… you don't express an order requirement there.
Jannik Luhn:But yeah, that would be, I guess, an interesting… like, if there are lots of these bundles, then it's potentially problematic.
Justin Florentine (Besu):We should… we should write this problem down and outline it maybe a little bit more clearly, give it a name.
Justin Florentine (Besu):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.
Anders Elowsson:And we discussed the issue of,
Anders Elowsson:Of, of, of, they, they, they have this, this,
Anders Elowsson:This… this functionality where they… they do these, order flow auctions.
Anders Elowsson:And,
Anders Elowsson: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…
Anders Elowsson: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.
Anders Elowsson: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.
Anders Elowsson:But it's also possible to, to enshrine that
Anders Elowsson:An order from the same decor.
Anders Elowsson:Or as key provider in ATA1 certifying.
Anders Elowsson:Would be, would have the same…
Anders Elowsson:Yeah, but to have retained order.
Justin Florentine (Besu):To me, that feels like something that we could add on later. Do you…
Justin Florentine (Besu):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 (Besu):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 (Besu):Okay.
Justin Florentine (Besu):Okay, then let's… we'll… we'll research this bundle issue a little bit better for our next meeting.
Justin Florentine (Besu):To discuss. We've got 5 minutes left, I want to be mindful of time.
Justin Florentine (Besu):Anything else folks want to discuss?
Justin Florentine (Besu):Anything folks think they're gonna wanna discuss at our next call?
Justin Florentine (Besu):Possible agenda items.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):Then, sounds like we keep grinding on our EIPs.
Justin Florentine (Besu):Stay in touch on Telegram.
Justin Florentine (Besu):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 (Besu):Absolutely, I can open one, I can open one immediately.
Jannik Luhn:Perfect.
Justin Florentine (Besu):Alright, thanks everyone.
Justin Florentine (Besu):See you on the internet.
Anders Elowsson:Thanks.
Kevaundray Wedderburn:Yeah.
Fabio Di Fabio:Right, bye.
Chat Logs
Summary
12 highlights
· 3 action itemsExperimental
Summary
12 highlights · 3 action itemsExperimentaleip 8105 updates
- Two-slot execution design: encrypted tx (block N) + decrypted tx (block N+1)00:08:47
- Execution context references previous block to prevent builder communication00:09:55
- Envelope signer reference added to prevent envelope stripping attacks00:10:16
- EIP-8105 PR merged yesterday with all new changes00:12:04