Encrypt the Mempool Call #5

Transcript

EF Zoom Bot: Hey, did you guys just join? I had to, like, fix the meeting, I think. It wasn't starting.

Gottfried Herold: Yeah, I mean, I was waiting for, like, I don't know, 10 or 15 minutes on the meeting link, yeah, so it said that basically the host was yet in…

EF Zoom Bot: Okay.

Gottfried Herold: previous meeting.

EF Zoom Bot: Okay, yeah, no, I'm aware of what it is, so yeah, sorry about that, but hopefully… Justin will join, but yeah. Sounds good. I am a human, by the way, I'm not a bot with just, very good, human sounds.

Gottfried Herold: Oh, and there's another link that was just posted on the channel. Maybe people are on the other one.

EF Zoom Bot: The channel in… is it in Discord?

Gottfried Herold: Telegram channel, there was a link posted in the Telegram channel.

EF Zoom Bot: Okay…

Gottfried Herold: You can forward it. I would prefer to keep the one… Maybe I just join and ask people to come back here.

EF Zoom Bot: Yeah, this one would be preferred, unless it's inconvenient, because I guess this one is recorded, and the other one, I'm not sure if it is.

Gottfried Herold: Yeah, I can go to the other one.

EF Zoom Bot: Nothing.

Gottfried Herold: Just leave and go to the other one and talk… and ask them to come back to the original link.

EF Zoom Bot: Sure, yeah.

Justin Florentine: Okay, Zoom, you win this one. You win this one.

EF Zoom Bot: Yes, yes. Oh, jeez.

Justin Florentine: Cool. Alright, well, thanks for rolling with the confusion, everybody. Anthony has, jumped on the grenade, as we say in the US, and is staying back from the other one to redirect people here. So he'll be joining us shortly. Welcome to Encrypt the mempool number 5. Folks that don't know me, my name's Justin, I work on the Besu team, trying to help everybody get this mempool encrypted. We have a pretty big, agenda today, actually. A number of different things we're gonna, gonna cover. I'm just gonna bang through these real quick so we can try and make up for some of our lost time. We want to cover, getting to SFI. I think Yannick has some good ideas on how these things fit into a roadmap. I have a very rough sketch in our agenda of what it takes to get to SFI, so we'll cover that.

I think, frame transactions is a topic that keeps coming up. Do we want to build, Lucid on top of frame transactions? So there'll be a discussion on that. We are continuing to solicit support from consensus devs. I took a crack at the execution specs, it still needs a lot of work, so we need somebody to do that on the consensus spec side. We'll talk about that. And a couple of other tasks. At the end, Anthony will be rejoining us, and he'll talk a little about the Encrypted Mempool Coalition, and Loring has some interesting news about funding, and so what do we do with that? So, let's dive in, let's get started. Yannick, are… did you want to start off with, this draft roadmap suggestion?

And the EIP process?

Jannik Luhn: Sure, I can get started, yeah, so basically, as you said, we also… what we come up with is also not much more than a rough draft. We just think it would be good to have, like, a document where we write this down so that we know where we are, and we know what's left to do. We're probably not the best people to do this, but we still went ahead and started, just to have something That we can iterate on. So it would be great to have feedback on it. I can share my screen and…

Justin Florentine: Yes, please do. I actually started a Lucid PM repository in my own GitHub account to start doing some of this work to, you know, track overall status of the project. I took a page out of Jihoon's book. For the way that he managed the FOCIL project. I found that super helpful. So I think that would be a natural place for this to live. I'm happy to add you as a collaborator, and you can start putting these types of artifacts over there. Cool. Tell us what we're looking at here.

Jannik Luhn: Yeah, so, Basically, this is not timing yet, this is just work tasks that we think are necessary, split into core tasks, so everything that's needed for the actual protocol change, and then also ecosystem, like, stuff that's not actually needed for the fork itself, but needed for actual adoption of the stuff. And for every task, we also wrote and added, like, an entity or people who we would consider yeah, responsible, or who might be the best people to drive this forward, and of course, it starts with finalizing the IP, then what you just said, specs and tests, both on the execution and consensus side. Once that's done, the client teams kind of start the implementation on both fronts.

Followed by definet, testnet, and finally the fork itself. For the definet, it probably makes sense to also have some testing infrastructure helpers. The thing I'm thinking about there is basically decryptors, that, or kind of test decryptors that provide keys, which the clients obviously do not, but are needed for a proper DEFNET.

Justin Florentine: I think we, I mean, we also need sandwichers, right?

Jannik Luhn: Yeah, maybe even that, like, kind of attackers and test users and this sort of stuff that would probably also fall in that category.

Justin Florentine: that I would add in here is between… the implementations and the DevNets, there are some other test suites that we want to make sure that we're, working on, like the Hive test suite, which is a more higher level, holistic way to drive an Ethereum network. That's probably going to be an intermediate step before we go to DevNets as well. The finalized EIP bar is great, I love that, but I would make it last the entire length of this, because… this thing is gonna be in draft pretty much forever. Like, I don't know how often you go into the EIPs and look at their status. They are in draft right up until the hard fork hits.

I think it's reasonable to say, like, it's good enough right there where you've got it, good enough to start working on, but we do want to capture that there will be a feedback loop, and all the things that we're learning along the way will probably require updates to the EIPs.

Jannik Luhn: Yeah, so maybe finalize is the wrong word, maybe it should be, I don't know.

Justin Florentine: Draft is good. Maybe there's two bars there, one that says draft, and it's just like you have it, and then there's a second one that says revise, and it runs the entire, entire length of it, yep.

Jannik Luhn: That sounds good. Yeah, and on the ecosystem side, we're thinking probably we need some updates for the Node RPC adjacent RPC specs, for example, to get the status of a transaction, which might now look a little different for the encrypted transaction. Because it might be… yeah, maybe the key did not arrive, or the key did arrive, so the wallet wants to have information about that. And for decryptors, we think, like, if you have a TE encryptor or a threshold encryptor, they probably want to have standards how they interact with wallets, how, like, a wallet that requests keys or asks if a decryptor is online and able to provide keys. This sort of stuff, I think it would make sense to have specs for that.

Or at least an example spec, because decryptors, they might have different interfaces. And, then for, in particular, the testnet, we probably want to have some example decryptors, live. Again, different variants, maybe TE, maybe threshold-based, and also centralized ones, maybe, for testing. Yep, so that's what we've got so far.

Justin Florentine: That is awesome. I will put you on as a collaborator to my PM repo, and anybody else that's interested as well, just hit me up, I'll add you as a collaborator, and we can… I was thinking that would be a place for artifacts like this, links to different branches that will have these different execution specs. etc. And we can open… we can even use the issue tracker there if we want to be able to assign these things to different people. So thank you, Yannick.

Jannik Luhn: Cool, sounds great. Thank you.

Justin Florentine: Alright. Let's see, what else did we have coming up next? Execution specs. Very draft PR in progress. Let me share my screen… Done… okay… Should all see my browser… And so… This is… oops, I already had it open there. For those of you that have not worked on the execution specs before. You may be surprised to see how huge this is. Okay? 14,000 lines, it's all green. There is a convention in the execution specs where Every fork is self-contained. Okay? So, essentially what you do is you copy over the entire execution spec from whatever fork or branch you're going to be building it off of. And you started from scratch.

Okay? So each one needs to be self-contained. I started this from the Fusaka brand. I'm sorry, the, yeah. Yes, the Fusaka branch where FOCIL is scheduled. Alright, because we do rely on FOCIL for a number of things. However, there are also some things that are in Glamsterdam, that need to be… that needed to come over as well, specifically Slotnum. So, I… I would recommend, if anybody wants to take a look at this, I can provide a list of, like, here's the stuff that actually changed. Me and Claude kind of, this is mostly vibe-coded. We do have a list of the things that… isolate the changes, so you can look here, this is my own PR review. Many of these things are already viewed because…

they didn't have changes, or I've already reviewed them and added comments. Okay? So this is a long way of me saying, it's a big boy, don't be intimidated by it, we might have to trade notes back and forth on areas to look at and areas to review. All input is welcome. Like I said, it's very much in draft, it lives in my fork for now, and it's going to be a long… a long journey to get this thing in shape. Any questions on that? How do people feel about building on framed transactions or not? So, for example, you may have seen me in the R&D Discord pestering the framed transaction team about, hey, where's your execution specs? Where's the execution specs? They don't have it yet, they're still working on it. Totally understandable, because their thing is just as complex as ours.

And so the question is, it's like, well, what do we, what do we do about that? I hear that Yannick might have an opinion on that matter.

Jannik Luhn: Somewhat, so… Basically, what we've been thinking about is frame transactions not in the context of the EIP, but in the context of, the encrypted mempool, project that we have going on with Primev, where we build on builder commitments, basically. so… Should I give an overview over that? Because it's not really related to the EIP. I don't think it's, it changes anything in the EIP, but maybe, like, at least for me, it was interesting to understand, like, a potential different approach.

Justin Florentine: appropriate to present a different implementation so we can see how it works and how it, we can learn from it. Would you like to share?

Jannik Luhn: Yep, sure. So, basically, so… The nice thing about building equipments is that they don't require any protocol changes to Ethereum, so they can be implemented much more quickly than the EIP that we're discussing right now. But on the other hand, it's also way more limited, because the enforcement of the rules is more limited, because we can only rely on slashing, we can't just make blocks illegal or invalid. Or transactions invalid, or anything like that. So the kind of naive way we've been… that we've been implementing so far is to, I mean, general process is, the user encrypts their transaction, they send it to a builder, the builder then commits to including it. once they're committed to including it in the next block, they will receive the key, and then they kind of have to include it in the block if they build it. If they don't do this, or if they build a different block, they get slashed.

The problem there is that the builder does not have a guarantee that they will be able to build the block at all. They might lose the auction, and also they might just give the transaction, once they have it, to another party, to another builder. They might then build the block, and since they are not participating in this protocol, they're not staked, they can include or front-front their transaction without getting slashed. And we can't even slash the original builder who forwarded the transaction, who leaked the transaction, because it could have also been the user itself. So there's kind of a non-attributable problem there. So… that's why… at least I was not particularly happy with this protocol, but now I've looked a little bit into frame transactions and realized that we can actually do quite a bit of enforcement there of these rules, because frame transactions do allow us to make transactions invalid, according to custom rules that we can define.

And the rules that we need are actually quite simple, we just, require two signatures, basically. The user has to sign the transaction, and the builder has to sign the transaction. And since, kind of, both parties have to sign off, Yeah, passing the transaction or giving the transaction to someone else is not, not possible anymore, because, yeah, then we could slash the original builder.

Justin Florentine: Are there any links to this design that you could share?

Jannik Luhn: Not yet. We haven't written it down properly yet, but I can, I can write it down and send it around, I guess. Yeah, and…

Justin Florentine: Yeah, if you wouldn't mind, I think that would be helpful. I'd love to run that by Anders, also, and see if it gives him any ideas.

Jannik Luhn: Yeah, in general, what may surprise me about this is that there are actually quite a bit of rules that we can define now, in code, outside of the protocol, and that might be interesting in the AP. I don't think… yeah, I don't have a good enough understanding of the API to evaluate if there are things we can outsource, basically, but maybe Anders has thoughts about this.

Gottfried Herold: Yeah, actually, I may have a bit of a question about, regarding the relationship to freight transactions from someone who actually, understands the AIP quite, quite a lot. I mean, in the, actual, Lucid EIP, we have basically two things that go on-chain. One is the transaction ticket, and the other thing is sort of the individual transaction, after, sort of, it gets decrypted. So in the context of frame transactions, what do you want to sort of build upon atop the frame transactions? The actual, ST ticket? Or the decrypted transaction. Because, from my point of view, I mean, the latter is kind of… Easy, but does not give us as much? The much more interesting but rather difficult part is more the first part, where basically you have the, sealed ticket, which, as of now, is only part of the,

of the beacon block, but not much of the execution part, which is a bit problematic in the sense that the Timeliness Committee actually has to Or basically make some unpaid-for, as of now, validity check. that is sort of related to the PTC votes and also to attester votes, based on the validity of these, entries there. And if… I mean, it would be very, very helpful to actually allow for some kind of… Well, customizable authentication mechanism there, and to be frank, if we ever want to go post-quantum, we actually need this. But sort of having here something that is much more heavy, is potentially a bit problematic, I think. I'm not sure whether there's any ideas regarding that.

Justin Florentine: I had not considered it. This is… I, I think…

Gottfried Herold: I think…

Justin Florentine: Yeah, I mean, I see what you mean by, you kind of really need to be, you know, both the ticket and the plain text transaction need to be on.

Gottfried Herold: I mean… I mean, the transaction is kind of the easy part, I mean, easy comparably, and there's kind of clear what you would have to do, but I think the much more interesting part is the ticket, because right now we basically enshrine the… Right now, the EARP basically enshrines the usual litter curve-based signature that we have on the ticket part, and this is kind of the lightweight part of the protocol, by design.

Justin Florentine: It ends.

Gottfried Herold: And…

Justin Florentine: But it's also the early part of it, right?

Gottfried Herold: The what?

Justin Florentine: It's also the early part of it. It's how we are able to kind of get out in front of when the plain text transaction needs to be executed, and make sure that the.

Gottfried Herold: Exactly.

Justin Florentine: Exactly. Exactly.

Gottfried Herold: But for this, it's actually… I mean, frank transactions are actually much more useful, also, for this part, not just… I mean, first of all, it's the security part, because we want to have some kind of quantum part. The other thing is that an actual correct usage of Lucid would, in fact, in order to hide, Sender, identity, which is something you absolutely want for, To protect against, probabilistic front-running attacks, you would actually have to make sure that your, the ticket is actually sent from an… and from an address that is unlinkable to the one that is actually doing the transaction. So, essentially, correct usage of Lucid would mean that you make some stealth, or Tornado Cash, or Railgun, or whatever transaction first to some other sort of temporary, one-time

Paymaster, basically, let's call it, and then use that one to sort of send your, ticket. transaction from. And then, you basically have to burn it, because you can only use it once, really, because you really need this kind of unlinkability. And using some kind of frame transaction or account abstraction framework for this, where you can avoid the horrible UX that this gives you, would actually be extremely useful. So, just from a UX point of view, you also want it for that reason alone.

Justin Florentine: Interesting, so… yeah, so it opens up account abstraction used as a validator for the STO along the frame.

Gottfried Herold: Yeah. I mean, just, I mean, it's very kind of orthogonal to lose it, it's just something to consider, because, I mean, technically. I mean, from a UX point of view, you really want to have a much more complicated logic here. Or there is use case, there's a lot of use cases, I think. The other one.

Jannik Luhn: What's a good…

Gottfried Herold: security aspect is post-quantum security. So, I think we need it. Eventually, we need something like that.

Jannik Luhn: And putting it all in Lucid itself would make it much more complicated, and probably not necessary, so that would actually require less if we could have that.

Gottfried Herold: Yeah.

Jannik Luhn: Kind of inherit that from frame transactions.

Justin Florentine: Okay. I think I need to party with that thought and maybe write up some different scenarios. that express… What we're imagining here, right?

Gottfried Herold: Hmm.

Justin Florentine: maybe some use cases. That might be a thing that anybody can also help with, Gottfried. If you, if you… You sound like you see this fairly clearly, because you're saying that it's likely necessary, not just.

Gottfried Herold: I mean, necessary from the point of view that we need, post-quantum security on the transac- on the signatures, on the… on the tickets.

Justin Florentine: Neeee.

Gottfried Herold: I mean, that is kind of the clear part. The other thing is not so much necessary, but it's really more a UX thing, that it is, You have bit… yeah… you technically, you would want to pay directly from a Tornado Cash pool or something. That would be extremely useful to have, that basically the pay… you can sort of use a paymaster that sort of…

Justin Florentine: Anonymous.

Gottfried Herold: A secondary paymaster, because otherwise you have to sort of shuffle around funds into some temporary accounts that you only use once to sort of send out a sealed transaction ticket.

Justin Florentine: Okay, that's… now that's an interesting use case that maybe we can diagram out and actually say, okay, if it was on the transaction. How would you set up an anonymous paymaster from Railgun to cover your transaction?

Gottfried Herold: Yeah, I mean, you still need some kind of one-time usage accounts, but at least you don't have to fund them every time.

Justin Florentine: Yeah.

Gottfried Herold: I mean, it also depends quite a lot on whether we ever will have some enshrined privacy solution for, sort of, anonymous transactions, like CK wormholes or whatever. I mean, in some sense, I feel like, like, this is out of scope for Lucid. It's just that Eventually, you will have to use some mechanism like… some kind of mechanism like that, because you need an… you… technically, if you… for security reasons, you really need an unlinkable, sender for the… for the ticket, rather than… rather than for the sender, for the actual executor.

Justin Florentine: Okay, so, ways to anonymize ST senders. Yeah. Yeah. Cool. Anybody else want to chime in? Okay, sounds like frame transactions are promising and interesting, and we should continue… researching in that direction. I will, run this by Anders, and I'll see if I can maybe… Design a use case that exemplifies this idea. Cool. Right, moving right along… what else do we have here? Execution spec test, TBD. So, yeah, the other bullet points here are kind of just Filling in… this is more of a status report type thing here, let me share this.

next things that need to be done, right? So, started working on execution specs, and at some point you're gonna need execution spec tests that… that are more than just the things that are automatically generated that cover the happy path, like. We're gonna need to really write some stuff that probes at some of the corner cases and use cases of the feature as defined in the EIP. I don't know that we're ready to do that, but that is definitely a next item that we need to have somebody Thinking about. So, if you know somebody that is familiar, likes to conspect tests, see if you can recruit them. Speaking of recruiting people… I am not a consensus developer, and we don't want this.

So, I don't have experience doing, CL spec work. I have to take a crack at it. But we really need… I need a partner from the CL that wants to… whoops. It's over here… that wants to help work on this stuff. So, you know.

Loring: That's the name.

Justin Florentine: Go ahead.

Loring: If you would like help reaching out to the consensus client teams and seeing if we can find someone who is interested, and able, then Anthony and I can support on that. I think if you give us a little blurb about what's needed, we can do the legwork.

Justin Florentine: Great. That would be awesome. I'm trying to think of the blurb. Maybe I'll just write down that I need to get you a blurb, and we can think about that later. I think it's really, like… I think it's kind of this. I need somebody to help write the consensus specs. We're gonna need an implementation at some point, I think? But maybe that could be a different person? Maybe… Yeah, maybe it's so far in the future it's not worth engaging somebody on it yet? Alright. Let me talk… actually, let me talk to some CL devs to figure out what exactly should go into the blurb, because I don't… I don't even… I don't even know where to start, honestly.

I got a couple people in mind. Okay.

Loring: And just to mention, later on in the call, we're going to talk about funding, so there might actually be some way for us to incentivize, a developer or client team to take the lead on this.

Justin Florentine: Yeah, that'd be great. Put on a bounty on it. Cool, another TBD hive test. I already covered that, I think, in our early look at the… loose roadmap that Yannick presented. It's a thing that needs to be done. EL client implementation. I'm planning on doing this in Besu, because I'm a Besu dev. I think that's fine for getting us to SFI. I don't know that we need to do it, or try to do it in more than one client. It would be rad if we did. But that's, you know, something to consider much further down the road. And then CL compliant… CL client, we talked about that as well. So, my plan is to take these TBDs and put them in that Lucid PM project thing that we were talking about, and use that as the…

Artifact to share with people that we want to recruit into doing it. Cool.

Loring: Justin, a question on the, implementations. Is it… normal or preferable to have one implementation from one client team first, and then let the other client teams kind of use that as a reference when making their implementation? Or, does it make more sense for Different client teams to, do different implementations in parallel.

Justin Florentine: Generally, the former. You know, if for some reason you had an embarrassment of riches, and you had tons of people excited to work on it, I don't think the latter would be a problem. I think it's gonna happen eventually anyway, that people are going to build different implementations, and they're gonna conflict, and they're gonna find things. You know, the earlier that you figure that out, the better. The more brains you get trying to implement things in different ways, the better. So, I don't think it would be problematic, but it's also really hard to say, like, hey, everybody go, or, you know, more than one team go and do this when they're, you know, we're not even sure if it's gonna go in.

So yeah, I don't think it's a problem to do it in parallel, it's just more orchestration overhead.

Loring: Okay. I know that, Erigon client was, one of the… primary advocates of Lucid during the Hegota headliner discussions, and they also expressed an interest in developing The encrypted Mempool EIP, in preparation for the next round of decisions, and so I can reach back out to them and.

Justin Florentine: That would be awesome. They'd be a great candidate, because they also have their own CL.

Loring: Okay, wonderful.

Justin Florentine: Yeah. Nito. You know, Erypt the Memphil Coalition. Anthony, what's that all about?

Anthony: Alright, so what we've been wanting to do, in the other call, we have our second call, the Business Marcoms. I was working together with Ivy, Loring, got some feedback from others about, how can we rally support together. And so, what we've been doing is we've been putting together some criteria. for interested parties, organizations, whether they're wallets, privacy projects, client developers, and so forth. People that just want to get involved and show support for it, and want to contribute and raise awareness. And so, we're going to be launching a campaign tomorrow. with a website? To generate awareness, and use it as an opportunity to kick off momentum. So we're gonna be launching a webpage, and then we're gonna be launching, a tweet announcement with,

what am I at? I think we're at something like, I don't know, 20 partners or organizations so far? So, it's quite exciting. I can share my screen. So… yeah. Besu… BTCS, Eigenfi, Erigon, Fairblocks. We got Web3 Privacy just a moment ago. So we have a great variety of people, and the main thing we want to do is we want to get… we want to keep the list growing. And get as many people as possible, whether they're getting involved in joining these calls, or just showing solidarity. But we're quite excited to get people together for tomorrow to go and, build a little bit momentum, and then drive them to this website where they can get involved, whether they can join the tech working calls, or maybe they just go and they share it on X, and they tag their favorite wallet or DEX.

So, I will pop, this website onto the, main chat, but I encourage everyone tomorrow to go, like, share. retweet, and maybe try to get more people into the coalition. These are just the first group of people. We'll definitely be getting a lot more as we go. So… Yeah, that's what I wanted to share.

Justin Florentine: Thank you, Anthony. That is… great. I'm still working on consensus, I'd love to get Consensus' brand in there. We'll see, though.

Anthony: That'd be awesome.

Justin Florentine: Yep.

Anthony: Oh, Justin, one thing, though. After this call, can you go ahead and create the next, issue for the next working group call? That way, I can put it into the website, so it's, everyone knows where to go and sign up for the next one.

Justin Florentine: Yes. Cool. Awesome. Okay, thank you, Anthony, that was great. And then last on our agenda, I think Loring had something to discuss with regard to some some bounties that we made, or some money that has fallen into our lap. What do we do with it?

Loring: Yeah, that's right. So, BrainPot has been funding on behalf of the effort to encrypt the mempool, and there is kind of one pool of money which has already been confirmed, and two more which, may be available in the future. And so, I'm going to outline those different sources of funding, and then talk about some opportunities that we could use it. So the first is that Encryptimenpool received nearly $6,000 from the Dow Security Fund QF round, which was held Recently, and that money was recently, transferred to BrainBot, just a couple of days ago. Coming up in mid-June, EncryptoMempool, and Shutter will be participating in Octant Epoch 12.

Where this is kind of a classic QF round, where there's a pool of money to be distributed among 25 projects, and we're one of them. And then the last is… ShutterDAO0X36 has a, funding mechanism called Shutter Champions, and the current funding round is called Melee 2, where ShutterDAO0X36 is distributing, $10,000 to advance Shutter, and there is a process for submitting proposals and for voting in ranked choice, voting systems, on those limited number of proposals. I won't go into too much detail about Octant Epoch 12 or Shutter Champions Melee 2. I'll drop it in the Telegram chat so you have all the details on how you can participate.

But the bottom line is. We have $6,000, which we can use, if we have a good idea on how to. And there's probably more money coming in, within the next couple of months. So, my idea, or at least initial idea, and I would love to hear other ideas from members of the group. Is that social bounties could be a really powerful way for us to move the project forward, and achieve some very concrete milestones, and at the same time, demonstrate community support for the project. And… Let me… So, a social bounty is a bounty which is permissionless. anyone can create the bounty, and others can join the bounty by contributing funds to the bounty pool. And then, when someone puts up their hand and claims to have fulfilled the bounty, then each of the contributors has a pro-rata vote on whether the bounty has, in fact.

been fulfilled and should be paid out. Or whether, maybe at some point in the future, whether the bounty should be nullified and all of the contributors In which case, all of the contributors receive all of their funds back. So, a social bounty could be really powerful in this context because, as we've discussed earlier in this call, we can't encrypt the mempool alone. We need support from, consensus developers, from, testers, from, wallets, from builders, other Ethereum, ecosystem and transaction supply chain actors. So, instead of… kind of giving one bounty and saying, encrypt the mempool, we can break, specific milestones down

and say, for example, we would like one of the consensus client teams to write the spec for this EIP, and we're going to create a bounty, for that particular milestone. And then we can kick off that bounty today, if we wanted to, with an initial funding amount of $6,000. And then other people from around the ecosystem could chip in $10 or $10,000 in order to incentivize the consensus client teams in order to fulfill that milestone. And then, if none of them take us up on that offer, then everyone could get their money back. So this is just, one idea. I'm interested in hearing from other folks in the group about if you have other ideas on how to spend money to advance the project.

Or if you have, ideas for specific bounties which you think we should initiate to achieve specific milestones.

Justin Florentine: Do you think 6 grand is meaningful as a seed amount, in that type of scenario?

Loring: Great question, and I honestly don't know. But one possibility is… I mentioned that Shutter Champions Melee 2 is, coming up. And that has $10,000, which… if people voted for it, could be used for a bounty. And so maybe we start off with 6,000, use Melee 2 to add an additional 10,000, and then encourage other people, to go from 16 to a higher amount.

Justin Florentine: Okay. And then, the other question that I had is… you know, do we spend this money on engineering, or should we spend it on marketing? Like, I feel like $6,000 is not a terribly… Useful amount for an engineer, but it buys a crap ton of… whatever marketing… I don't know what marketing costs, but it feels like it goes a lot further.

Anthony: I mean, I can chime in. I definitely can add value on different things, but I guess… what would be the most valuable thing we could do to move the needle to get us a little bit closer? If it's marketing, we could do that. If it's something more technical. We could do that as well. So, I guess we could kind of keep the dialogue open and brainstorm a few different things. I'm very limited on my knowledge, because I only know the marketing bit, so…

Justin Florentine: I actually think the marketing bit probably is more effective over the long term, and I'm just thinking this out now. You know, 6 grand buys you some engineering time for stuff that may or may not work. But 6 grand also buys you, like, inertia and vibes and a lot of that stuff that you're also gonna need to ride all the way through this project, right? When you get to the end and you're actually trying to figure out, like, okay, are we gonna commit to putting this on a hard fork and shipping it? Those vibes are gonna come in handy more than $6,000 worth of engineering at the beginning of a project, I think. So right now, I'm going to continue thinking about it, but right now, I think that it's probably better well-spent marketing.

Loring: One thing to add is a bounty for specific engineering milestones may actually serve both purposes. And, Justin, you'll recall that in a recent call, I forget whether it was the last tech call or a MarCom's call, we were talking about how… core developers and client teams sometimes have a lack of feedback mechanisms. In other words, they have trouble getting signals from the Ethereum community on what they should be prioritizing and building. And maybe… By creating, and ceding a bounty, it gives people an opportunity to contribute in a small amount, and then when it comes time to discuss inclusion of the EIP, the most meaningful contribution of the bounty is not going to be paying for engineering work, it's going to be us pointing to the bounty

Or bounties, and saying, there have been 5,000 people who have… put their money where their values are in order to see encrypted mempools be implemented in the Ethereum core protocol. And that could be a really strong, kind of demand-proof point going into those discussions.

Justin Florentine: Okay. I find that compelling, thank you.

Gottfried Herold: Okay, good.

Justin Florentine: African? Oh, sorry, I thought you were raising your hand. Cool. Awesome. I'm gonna ask around for some other people that know more about funding than I do, too, get their opinions.

Gottfried Herold: Just something I wanted just to announce here, sort of related to this, because, I mean, it's a bit of… like, sorry to be a bit of a party pooper here, but there's one thing I just wanted to say here, is that, I mean, I'm currently planning to write a bit of a criticism on Looted specifically, just because I think a lot of what is sort of out there in the marketing often does focus more on the sort of what we do side of things, but from a security standpoint, I mean, I'm a bit of a photographer, sort of a security-focused person, so this is often basically a bit my job to sort of be a bit of the devil's advocate here, is that we have all of these kind of optionality issues, and so on. And,

oftentimes, I mean, if you sort of talk to, okay, what the encrypted member in particular Lucid is, it's often very, very unclear to sort of outsiders of, okay, yeah, Lucid is one proposal, it sort of solves certain things, but it has certain issues, and so on, and I think we should be a bit careful to oversell this. Just as I said, I mean, I will probably write down a bit of a comprehensive criticism, just to make, sort of, this a bit more publicly visible, in order to have, sort of, a meaningful discussion. And regarding, sort of, these, kind of, where we put the money or the bounties on, especially for marketing, I mean, I'm completely, sort of, in favor of, sort of, marketing for the need for encrypted mempools, but, I mean, there's a bit of a danger in sort of marketing, sort of, Lucid as the one single proposal that, sort of, fixes this. I think we need to be a bit careful not to oversell the cutter solution that we have.

Justin Florentine: I think that's spot on, yeah. I don't think… I don't think any of us are really married to a particular design, and we welcome the criticism. I would even fund more, like, steel man, straw man arguments.

Gottfried Herold: thought about some kind of alternative, sort of in the last couple of weeks, basically using some ideas for Lucid to sort of re… re… sort of revive the shutter network proposal by using some FOCIL-style mechanism to solve these issues. It doesn't solve the problem, it just makes it a bit closer. It basically brings it, I don't know, from 100 yards of to, being, made, doable to, I don't know, 90 yards?

Justin Florentine: Yeah.

Gottfried Herold: Slightly, but, yeah. But, I mean, there's still a lot of going on there.

Justin Florentine: I think that's great. Thank you for doing that, Gottfried. Lauren, go ahead.

Loring: Yeah, Gottfried, I think that's a very valuable contribution, and maybe a bounty, just to kick things off, might be, a general bounty take a look at the draft EIP and suggest opportunities to improve. Or, be a naysayer, and we'll give a $6,000 bounty for the strongest criticism, the biggest weakness of a proposal, right? So, I think there's… A lot of interesting opportunities here.

Gottfried Herold: Yeah, I mean, that's just… just wanted to sort of put this up also, that you're not sort of surprised if I write something that, hey, I'm sort of the asshole in the… in the team, just a bit of, clarity here, and also…

Justin Florentine: good, we're all on the same team. The real enemy here is Jared.

Anthony: On the note of Lucid, I definitely like that approach to be balanced and everything. I mean, so on the webpage that I put together, I put Lucid as, like, the main thing we're kind of moving towards.

Gottfried Herold: Yeah.

Anthony: I could scale that back, because I agree that we should be balanced, we should provide different things, but I guess I just want to do a quick gut check. I mean, I guess I shouldn't scrub the page of Lucid, but, should I caveat and just say, like, we want to encrypt them in pull? It's not necessarily…

Gottfried Herold: I mean, I can have a look at…

Justin Florentine: I think you want to both caveat it, and you also want to reinforce the idea that it's ongoing and revised. Like, it is in a draft state, and we've thoroughly plan on input coming from a wide range of places, and it's very likely that it looks Maybe it only has, like, a small bit of Lucid left in it by the time you end up shipping it.

Gottfried Herold: I mean. just to give a bit more concrete criticism, there is at least one kind of security-critical bug that is fortunately easy to fix, that I just spotted last week. Then there is sort of in the… as far as the AIP is concerned, we have sort of not yet fleshed out how the actual sort of metastational rules or consensus rules changes are. It's just not… not really fleshed out. We have all of these friend transaction things, we have the account abstraction things that, sort of. Needs to be integrated, potentially, so there's a lot of drafty things here. Then the one thing, I mean, I have not looked at the website yet, just one thing that I might… you might want to be a bit careful is about this kind of future-proofness and sort of agnosticism.

that is something I would really tone down, because, I mean, this agnosticism, sort of selling it as future-proofness. if I think… I… from a cryptographic point of view, I think it's actually incorrect. Because, I mean, this agnosticism is nice in a way, but it's sort of… in some sense, future-proofness or agnosticism gives you sort of the best of all potential options in the context of an encrypted mempool, where basically the user… basically, the adversary may choose whatever solution they like, and actually gives you the worst of all potential solutions. So, and it's sort of… you could sort of envision some future proveness where you basically eventually say, hey, we have this kind of Lucid-like design, and later on, we enshrine one or two, whatever, isolated solutions, and only want to use those four, but the way Lucid is designed, it's not really fit for that purpose, necessarily. Because if you were to enshrine something, like, I mean, currently working on some design using just threshold IBE, you would want to do things very, very differently.

So…

Anthony: That's a good point.

Justin Florentine: Yeah.

Gottfried Herold: future-proofness, I mean, Lucid is basically the best we can do, given the current technology. just be aware that if we had, I don't know, a magical, super-duper threshold encryption scheme that would basically check all the boxes that we want. Then, sort of, we would basically have to go from scratch. Just… this is just the honest… just… just be honest about this.

Justin Florentine: Okay. Yeah.

Anthony: Makes sense. Cool! Yeah, if anyone has time, please have a look at the page, see if there's any edits I can make, for tomorrow. I get online. I wake up before everyone else, so… I can make edits quite early.

Gottfried Herold: Ugh. Nice. Yeah, I will have a look, being sort of the… sort of the critical guy. Sometimes you need a better side.

Anthony: I appreciate that.

Justin Florentine: Well, that's our time. Thank you, everybody. Good call, lots to do. Stay in touch, see you on the internet.

Anthony: Alright, encrypt the Mempool!

Justin Florentine: Encrypt them.

Loring: Drift the Mempool!

Gottfried Herold: Yeah, encrypted.

Loring: Thank you, guys.

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