Justin Florentine (Besu):Let's see, let's see, let's post the agenda here so folks can get to it.
Transcript
Justin Florentine (Besu):Oh, which I… closed. I don't know. Why would I do that?
Justin Florentine (Besu):This is meeting number 1, because we already have meeting 0.
Justin Florentine (Besu):Agenda is here in the chat.
Justin Florentine (Besu):Thanks for joining, y'all, we can get started, couple of things to discuss.
Justin Florentine (Besu):You probably heard already, EIP8105 has been withdrawn. This was the Universal Encrypted Enshrined Mempool design. It has been withdrawn,
Justin Florentine (Besu):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.
Justin Florentine (Besu):Speaking of elusive design… There's an EIP that just got published this morning by our own Anders Ellison.
Justin Florentine (Besu):Hi, Anders, welcome.
Justin Florentine (Besu):That's… this is the link to the pull request for the EMS.
Anders Elowsson:Yeah, let me share the link.
Justin Florentine (Besu):Yes, sir. You got it.
Justin Florentine (Besu):I just put it in the chat.
Justin Florentine (Besu):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.
Justin Florentine (Besu):Further discussion should be directed to the pull request, or asynchronously, you know.
Justin Florentine (Besu):But if you have… Ideas for improvements to it.
Justin Florentine (Besu):Please, they are welcome.
Justin Florentine (Besu):Okay, with that, I think we kind of open up the floor here.
Justin Florentine (Besu):To questions, comments, and concerns.
Justin Florentine (Besu):I think one of the things that I wanted to talk about was…
Justin Florentine (Besu):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?
Justin Florentine (Besu):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…
Justin Florentine (Besu):who has thoughts on that? I know RPC providers do provide the beacon chain RPCs?
Justin Florentine (Besu):So they're out there, they're usable.
Justin Florentine (Besu):But, what do folks think about that?
Justin Florentine (Besu):Correct, Yakim. 8105 is being withdrawn.
Justin Florentine (Besu):And LUCID is… Going to take its place.
Justin Florentine (Besu):No thoughts on beacon chain RPCs?
Justin Florentine (Besu):I'm not a CL developer, but I was fine with it.
Justin Florentine (Besu):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…
Jannik Luhn:Annoying, but it is what it is.
Justin Florentine (Besu):So.
Ben Adams:I mean, that's… Optional, is that correct?
Ben Adams:You don't have… not everything is necessarily forced to be encrypted.
Justin Florentine (Besu):Correct, oh yes, correct. This entire feature is optional, that's correct.
Justin Florentine (Besu):So it would be an update to an existing RPC method and the addition of a new one.
Justin Florentine (Besu):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.
Justin Florentine (Besu):So, new, new event.
Justin Florentine (Besu):You can find this in the section called Beacon Chain RPC API Changes in EIP.
Justin Florentine (Besu):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 (Besu):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 (Besu):Okay, yeah, it would be one new method that needs to be specified and updates to an existing method.
Justin Florentine (Besu):Okay.
jochem-brouwer:Yeah, maybe, maybe to ask, because this PR dropped 40 minutes ago,
Justin Florentine (Besu):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…
jochem-brouwer:could not beat the PR in 1 minute or 40 minutes, yeah.
Justin Florentine (Besu):Sure.
Justin Florentine (Besu):Sure. So, Anders, would you like to do this one, or do you want me to go for it?
Justin Florentine (Besu):You're on mute.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):Well, Anders… I guess I'll go.
Justin Florentine (Besu):So, yeah. The pitch for LUCID essentially is a two-slot design.
Justin Florentine (Besu):where… Users reveal their ticket, essentially, that claims a portion of the block space.
Justin Florentine (Besu):Where they say, alright, I'm gonna be sending a transaction, it's currently encrypted, and…
Justin Florentine (Besu):Here's my ticket that kind of reserves it in the next block.
Justin Florentine (Besu):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.
Justin Florentine (Besu):The wallets will then reveal their keys.
Justin Florentine (Besu):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.
Justin Florentine (Besu):so that's kind of the high-level elevator pitch. As far as pitfalls, I think,
Justin Florentine (Besu):You know, it prevents… it only prevents front running.
Justin Florentine (Besu):It really is, is, like I said, it's more of a transaction ordering fix.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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,
Justin Florentine (Besu):into the encrypted.
Justin Florentine (Besu):The LUCID block space, if we think of it as its own block space.
Justin Florentine (Besu):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.
Justin Florentine (Besu):What are some other pitfalls and shortcomings, The… Folks think should be brought.
Justin Florentine (Besu):to light.
Justin Florentine (Besu):Anders, Julian, anything you want to add?
Justin Florentine (Besu):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…
Justin Florentine (Besu):slot N plus 1.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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 (Besu):Okay, great.
Anders Elowsson:do not reveal your encryption key. We have, in this latest version, instituted a penalty.
Anders Elowsson: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.
Anders Elowsson:And if you, decrypt your transaction.
Anders Elowsson:Such that you, you, you reveal, the transactions that matches the, the, the commitment in the ticket.
Anders Elowsson: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.
Anders Elowsson: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,
Anders Elowsson:Top of lock fee that you paid.
Anders Elowsson: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
Anders Elowsson:lost, within the top of the block.
Anders Elowsson:And you may not be included also, because if someone else pays higher, then…
Anders Elowsson:Yeah, they would probably go before you.
Justin Florentine (Besu):Thank you, Anders.
Anders Elowsson:And I can mention one thing more, is that if you do not reveal, you also, the, the…
Anders Elowsson: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…
Anders Elowsson:And so it doesn't count against the Gauss limit of the look.
Justin Florentine (Besu):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.
Anders Elowsson:On which cases that are available.
Anders Elowsson:And, these PTC votes are, absurd, and,
Anders Elowsson:And the builder must adhere to whether the PTC voted that the keys were revealed or not.
Anders Elowsson:And so, you know if a key was revealed, if the decryptor address that was specified in the ticket released a key.
Anders Elowsson:That, that decrypted the transaction such that you get, something that matches, the, the reveal commitment in the, in the ticket.
Justin Florentine (Besu):Thank you.
Justin Florentine (Besu):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…
Justin Florentine (Besu):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.
Anders Elowsson: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.
Anders Elowsson: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…
Anders Elowsson: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.
Anders Elowsson:A lot of the rationale for censoring a transaction isn't there anymore.
Justin Florentine (Besu):Great.
mark:Well, that depends how long the transaction sits in the transaction pool, actually.
mark:Because you're thinking about, censorship, but there's also non-disclosure.
mark: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:Whoa.
mark:I think the thing is, you end up needing both.
mark:Right, because I think what encryption is doing is protecting you from the…
mark:Inclusion order issue, but also the information leakage issue.
mark: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?
Anders Elowsson: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.
Anders Elowsson:And the only reason you will have for actually census… like, the only mechanism for censorship in this case that is reasonable is
Anders Elowsson:If you, for example… you cannot blacklist one address, because you can hide this under…
Anders Elowsson: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…
Anders Elowsson:Quite strongly, even without going and using FOCIL.
Luis Bezzenberger:By the way, that's also why in EIP8105, there was…
Luis Bezzenberger:That was not the case that it went through via FOCIL, but rather just be a normal transaction type.
Luis Bezzenberger:So I just want to underline that point.
Anders Elowsson:Alright, cool.
Justin Florentine (Besu):Alright.
Justin Florentine (Besu):We've got about 10 minutes left. I'm happy to entertain more questions from the floor, if there are any.
Justin Florentine (Besu):Everybody's probably reading the EIP.
Justin Florentine (Besu):Is anybody here, representing builders? Or searchers?
Justin Florentine (Besu):I'd love to hear some input from…
Justin Florentine (Besu):From folks that, coming at it from that perspective.
Justin Florentine (Besu):Okay?
Justin Florentine (Besu):I have on the agenda to talk about bundling.
Justin Florentine (Besu):And ciphertext encapsulation.
Justin Florentine (Besu):Cipherdex encapsulation is kind of a new thing, that we're adding.
Justin Florentine (Besu):We're actually suggesting some symmetric encryption that should be used for the encrypted transaction.
Justin Florentine (Besu):And, you know, that's… that's a new thing. It's gonna use AEAD, as described in RFC 9180.
Justin Florentine (Besu):Which is a somewhat standardized ciphertext encapsulation format, so we'll have, you know,
Justin Florentine (Besu):suggestions on how to structure the data, and how it should be used. There is also, however.
Justin Florentine (Besu):header bytes, and extension capabilities. So…
Justin Florentine (Besu):While our suggestions right now are using, symmetric… Cryptography in envelopes.
Justin Florentine (Besu):That are, that are defined. There's nothing that prevents us from extending or creating entirely new ciphertext encapsulations.
Justin Florentine (Besu):I know that's a major concern for all of us as we look at our post-quantum future.
Justin Florentine (Besu):And so, with that regard, the encryption there is abstract.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):And then last thing is the notion of bundling.
Justin Florentine (Besu):Anders, where did we leave off on bundling with this, fi- not final, but…
Justin Florentine (Besu):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,
Anders Elowsson:The decryptor can bundle many different,
Anders Elowsson:Of these, sealed transactions into one, one singular commitment.
Anders Elowsson:And, this is useful because… for various reasons. One reason is that you…
Anders Elowsson:Yeah, so you release just one key message for all the…
Anders Elowsson: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.
Anders Elowsson:Depending on your encryption scheme. If you're a threshold encryption, for example, you will use one key.
Anders Elowsson:And target the specific slot for your transaction slightly.
Justin Florentine (Besu):Let's see.
Justin Florentine (Besu):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.
Łukasz Rozmej: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?
Łukasz Rozmej:Those are two things that come to my mind.
Łukasz Rozmej:Because, you know.
Justin Florentine (Besu):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…
Łukasz Rozmej:It's like an inheritance hierarchy.
Łukasz Rozmej:Right? So if we want to…
Łukasz Rozmej:add some new transaction with some new functionality, and it needs to be encrypted, you know? Now we cannot kind of…
Łukasz Rozmej: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 (Besu):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 (Besu):Sounds like blob transactions. Yeah…
Justin Florentine (Besu):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 | Besu:But, would that not make, like, a way of escaping this feature?
Luis Pinto | Besu:You know, in a sense.
Luis Pinto | Besu:Like, like, people… Could… could maybe, like, censor private transactions going forward, and only run the normal ones.
Justin Florentine (Besu):So, Fossil protects against that.
Justin Florentine (Besu):That's kind of why we refer to, like, the Holy Trinity of…
Justin Florentine (Besu):privacy features for Ethereum, right?
Justin Florentine (Besu):Proposer-builder separation, FOCIL, encrypting the mempool.
Justin Florentine (Besu):They all kind of lean on each other and provide different, different aspects in one happy little system.
mark:Yeah, it seems likely that you need all three, because in practice, if you're a regulated builder.
mark:You might well end up having a regulator saying, don't include…
mark:You know, this encryption and privacy thing is like a big red flag.
mark:Which is why I think if you're gonna do this, you end up needing Fossil.
mark:Which is not… it's not a technical thing, it's a… it's a legal thing, right?
Luis Pinto | Besu:What… what are the disadvantages of making everything encrypted from day one?
Justin Florentine (Besu):So, right, so we reserve, I think it's 1 eighth of the block space, for LUCID types of transactions.
Justin Florentine (Besu):And Anders, stop me if you'd prefer to speak to this. But…
Justin Florentine (Besu):You know, if you allowed the entire block to be…
Justin Florentine (Besu):encrypted, you kind of take us back to the bad old days of priority gas auctions.
Justin Florentine (Besu):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.
Anders Elowsson: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 (Besu):Right, and that's for payload withholding, not necessarily key withholding.
Justin Florentine (Besu):Got it.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):Well, we're at. Why is there a reserve space rather than some kind of gas auction mechanism?
Justin Florentine (Besu):I mean, I didn't explore that design space, did you, Anders?
Justin Florentine (Besu):Hmm.
Justin Florentine (Besu):Happy to, yeah, happy to pers- to follow up.
Justin Florentine (Besu):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.
Justin Florentine (Besu):My bad.
Justin Florentine (Besu):So does that answer your question, Lukaz? Andrew's response in chat?
Justin Florentine (Besu):Aye.
Łukasz Rozmej:I have a… Additional question.
Łukasz Rozmej:If I… not sure if I understood it correctly.
Łukasz Rozmej:Post it in the chat.
Justin Florentine (Besu):Okay.
Anders Elowsson:I don't quite understand your question in the shop.
Anders Elowsson:You have to…
Łukasz Rozmej:Okay, so what does it mean that you have reserved?
Łukasz Rozmej:What does it mean?
Łukasz Rozmej: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.
Anders Elowsson: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?
Łukasz Rozmej:What happened?
Justin Florentine (Besu):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…
Anders Elowsson:If you fill the block.
Anders Elowsson:And the biller is free to decide, then the builder is free to decide if they want to include them or not.
mark:So where did you get to the one…
Anders Elowsson:Sorry, where did you go?
mark:Yeah. Where did you get to the 1A?
Anders Elowsson:I frame it a little bit weird, because,
Anders Elowsson:Because… I shouldn't say it like that, because when you are a builder, you have already
Anders Elowsson:So, so we set the setting was 18. So when you are a builder, you have
Anders Elowsson: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.
Anders Elowsson: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.
Anders Elowsson:But those 1-8 have already been paid for beforehand.
Justin Florentine (Besu):Do we have a block validity rule that checks for that? That would be kind of…
Justin Florentine (Besu):Probably something that we should add, yeah?
Justin Florentine (Besu):Like, you know what the block limit's… you know what the gas limit's gonna be in the next block.
Justin Florentine (Besu):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.
Anders Elowsson:Of… you can at most include tickets that pay for and consume 1 eighth of the gas of the next block.
Justin Florentine (Besu):Okay.
Justin Florentine (Besu):Okay, well, we got time to kill. If folks, have more questions, throw them on out there.
Justin Florentine (Besu):If not, we are at the end of the agenda.
Justin Florentine (Besu):Alright, sounds like… It's time to wrap it.
Justin Florentine (Besu):Thanks everybody, you can find us on Discord and the R&D channel in the encrypted mempools.
Justin Florentine (Besu):Subchannel?
Justin Florentine (Besu):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.
Justin Florentine (Besu):So thanks, everyone, as always. And wallets, too, yes, 100%, please.
Justin Florentine (Besu):Wats need to use this.
Justin Florentine (Besu):So we need to make sure that we are hearing them.
Justin Florentine (Besu):Brad, feel free to reach out to me, Julian, or Anders.
Justin Florentine (Besu):With any… any concerns?
Justin Florentine (Besu):Thanks, everyone.
Julian:And do you adjusted.
Justin Florentine (Besu):You got…
mark:Okay, thanks.
Luis Bezzenberger:Thank you.
Jannik Luhn:Thank you, bye-bye.
Chat Logs
00:02:33
Justin Florentine (Besu):https://github.com/ethereum/pm/issues/1945
00:02:35
admin:/ff leave
00:03:34
Justin Florentine (Besu):https://github.com/ethereum/EIPs/pull/11376/changes
00:03:45
Anders Elowsson:https://github.com/ethereum/EIPs/pull/11376/
00:04:49
jochem-brouwer:To check, EIP-8105 is being withdrawn and being replaced by this PR to EIPs?
00:07:02 Łukasz Rozmej: I could use 5 min pitch of LUCID and another 5 min for its biggest issues and pitfalls ;)
I see CL RPC as a definitive nuisance.
00:07:20
Łukasz Rozmej:oh there is an EIP finally? :)
00:07:35
Anders Elowsson:Replying to "oh there is an EIP f..."
Yup 🙂
00:07:41
jochem-brouwer:Antwoord verzenden naar "I could use 5 min ..."
Yes and maybe the changes of EIP-8105 to this new PR, the PR dropped 40 mins ago 😅
00:08:28
Luis Pinto | Besu:I feel the meeting should be more about LUCID as a proposal as a headliner and why do people think it’s not ready for Hegotá
00:09:22
Anders Elowsson:Replying to "I could use 5 min pi..."
Easier to review changes relative to the LUCID research post. The biggest changes:
The ToB fee is moved to be public within the ST ticket
The transaction is executed against the previous block header
00:11:27
soispoke:One pitfall is the 1 slot delay no?
00:11:40
Ameziane Hamlat:Any overhead on the network side ?
00:12:42
Fabio Di Fabio:what happens if the encryption key is not revealed?
00:14:57
mark:If we do this in Hegota and we also do Frames how do the proposals interact.
00:15:58
mark:i.e. do encrypted tx's go into frames ?
00:16:59
soispoke:Replying to "i.e. do encrypted tx..."
I’m working on a post that explores this specifically (wip but will publish soon)
00:24:14
Łukasz Rozmej:I dislike the explosion of tx types, do you have any ideas how to avoid it?
00:24:40
soispoke:Replying to "I dislike the explos..."
Frame txns
00:26:05
Luis Pinto | Besu:Are we allowing normal and encrypted txs at the same time? Would that make sense?
00:26:06
FLCL:sounds like blob txs
00:27:47
Anders Elowsson:Also we are limiting how much of the block space that can be taken up by STs in the EIP
00:28:32
Anders Elowsson:Yup 1/8. Just as a starter
00:29:16
Luis Pinto | Besu:Ok so as a fallback
00:29:20
Anders Elowsson:Yeah
00:29:31
admin:The most common concerns on the ACDE were 1) not mature enough, 2) too complex, 3) unsure how it works with the rest of the roadmap.
Maybe we could quickly address those?
00:29:35
Łukasz Rozmej:why there is a reserved space rather than some kind of gas auction mechanism?
00:30:08
Anders Elowsson:Replying to "why there is a reser..."
How do you mean? It is the maximum, but you need to pay the base fee still
00:30:17
Anders Elowsson:Replying to "why there is a reser..."
So it is max 1/8
00:30:26
Anders Elowsson:Replying to "why there is a reser..."
In the first EIP
00:30:51
Łukasz Rozmej:Replying to "why there is a reser..."
but do I need to pay more than compeating transactions (either private order flow or public mempool?)
Like in FOCIL I need to pay
00:35:34
FLCL:Thank you!
00:35:47
Anders Elowsson:Thanks!
00:35:57
admin:Wallets too!
00:36:25
admin:Thank you!
Summary
13 highlights
· 2 action itemsExperimental
Summary
13 highlights · 2 action itemsExperimentaleip status
protocol design
- Lucid: two-slot design with tickets reserving block space, keys revealed post-inclusion00:09:07
- Prevents front-running; may reduce back-running efficiency by requiring full top-of-block backrun00:10:03
- Penalty mechanism: 1/64 of top-of-block fee retained if key not revealed00:13:02
- Ciphertext encapsulation uses AEAD per RFC 9180; extensible for post-quantum00:21:41
- Maximum 1/8 block gas for sealed transactions; expandable to 1/2 for catch-up00:33:12