Encrypt the Mempool Call #10

Transcript

Justin Florentine: Oh man, the zoom worked right off the rip!

Gottfried Herold: Hi, Justin.

Justin Florentine: Hey, Gottfried. Hey, Mark. Is this your doing? Is this why this is… Super reliable right now.

Marc Garreau: Yeah, man, maybe first time ever.

Gottfried Herold: I didn't do anything. Is it usually not working, just out of the box for you?

Justin Florentine: Yeah, it's… it's been a challenge, but we'll be Scottos. It's gotten better lately.

Marc Garreau: Okay, yeah.

Justin Florentine: David?

Marc Garreau: You are now officially the host.

Justin Florentine: Thanks, man.

Marc Garreau: Cheers. Have a good meeting.

Justin Florentine: Good seeing you, talk to you later.

Gottfried Herold: Nope. Let's see who joins today, because there is the protocol AMA.

Justin Florentine: Oh, and Reddit, yeah.

Gottfried Herold: Yeah, yeah.

Justin Florentine: I'm not…

Gottfried Herold: No, no.

Justin Florentine: Okay. Okay, okay, what's up, Mercy? Good to see ya.

Gottfried Herold: Nope.

Mercy Boma Naps-Nkari: Hello?

Justin Florentine: Anthony, welcome, welcome, welcome. Oh, am I supposed to… Recording… AI Companion is on… good. I had a real banger of a meeting yesterday that I forgot to record. That's gonna stick in my craw. Jannik's here, let's go, okay. Alright, we're reaching a critical mass! We'll get started in a minute.

Jannik Luhn: Hello, hello.

Justin Florentine: Let's post up our agenda. Some folks have it handy. Cool. Cool, cool, cool. Alright, welcome to Encrypt the Mempool number 10. We've got a little bit of an agenda here today, so some fun stuff to talk about. I'd like to get some of the housekeeping out of the way. First off. So, me personally, I'm gonna be running lead for the Besu team on Hegota. And those that are following along know that Hegota is starting to speed up. We're getting through the planning process, we've already got our two headliners picked, so anyway, there's a lot of work to be done there. This call is…

generally bi-weekly? We haven't been super, consistent on that, and I think that's actually going to be more of a risk moving forward. So what I want to propose is either A move these to monthly, or B, do them biweekly with the assumption that somebody other than me runs them On, an alternating cadence. Any thoughts or objections to that? I mean, I feel like… We're still very much in the design phase. I think we're still making progress. We're doing a lot of good communication asynchronously over Telegram, and so I don't… I don't know that this needs to be a… a biweekly meeting, and I'd like to change it to monthly, so… Any objections? Great. Cool. So let's get into it. I think…

Well, let's, let's do this backwards for a second here. PQ and threshold. Should we take those off the table? I feel like the idea of threshold encryption, is just not there yet, if we want to ensure that we're PQ. We did entertain the concept of, well, maybe this doesn't need to be all that PQ, for a little bit, but… That idea never really seemed very popular. And so… I would be willing to kind of… put a pin in that. I'm still following along all of the post-quantum signature discussions that have to happen anyway for Hegota. I'm… following along with the hash-based signature developments with SPHINCS, etc. And so, you know, I'm willing to kind of just take this off the table until we think that the crypto has gotten more mature, specifically with regard to secret sharing. That's the one thing that we really need to

Have as far as, you know, thresholds.

Gottfried Herold: I mean. I mean, secret sharing is… by secret sharing is sort of relevant here. I mean, the problem is that this is threshold encryption, or threshold decryption, which is a completely different beast to threshold signing and the like we need. It's kind of a very different cryptographic primitive. Regarding the PQ status…

Justin Florentine: Okay.

Gottfried Herold: But yeah, I mean, but still, I mean, the… the conclusion still stands as far as I can see. I mean, I think it's still off the table until the crypto improves. We have some, I think Benedict had some kind of… he's not here today, unfortunately. I think we had some kind of ideas to get something, but it's still not efficient, and we're still.

Justin Florentine: Yeah, the silent one-shot paper, right? The silent one-shot paper.

Gottfried Herold: I mean, Benedict recently had some idea of maybe one which might work, but at least even something conceptually that is EVQ is a cure, even something that is sort of one-shot and Silent with silent setup, and… NPQ, even something inefficient is sort of… I mean, we don't even have something inefficient, which is a silent setup. I mean, I might have some idea to get something, and PQ, it might have some idea to get something there, but still wouldn't solve the problem. There's just too much to be done in sort of… and it's just not there yet, and yeah. Probably won't be for years.

Justin Florentine: Okay, good enough. So, that brings us back to Lucid, our friend. And Lucid is… post-quantum secure as it stands right now, but unfortunately it has the optionality problem, and so that's what we're going to focus on discussing today. Let me just… pull this up here. So, maybe we can start with kind of our current ideas about preventing optionality, with a review of the notion of the key publisher. being kind of a role that's… I don't want to say enshrined in the protocol, but it is… or it's proposed to be… A somewhat trusted party. That would be neutrally responsible for revealing a key once an encryption transaction is committed to. Just as a reminder, this is… the optionality problem is exploitable because, you know, you can encrypt something, wait for it to appear on-chain, observe that, you know, your, bet, as it were, didn't go the way that you wanted to, and then withhold the key.

So, tasking another party, with, with the key reveal after the commitment, is, is an approach. The question is, like, well, how do we, how do we track that they're neutral, etc. Oh, Andrew's joined us, cool. So… Jannik. This is, this is right now, An idea that we've kind of talked about maybe a month ago, and The next step was, great, how do we… track and trust that neutrality, right? And you posted a paper, which I linked to in our agenda, capturing some thoughts on a potential approach for that. And so thank you for that. I think that's… that's really great work. I know, Gottfried, you posted a whole bunch of, responses to it in Telegram. I also took a bunch of notes on it, and so let's… let's kick that discussion off. Where do we want to start?

Jannik Luhn: If it's helpful, I could give a quick overview over the document, in case not everyone has read it.

Justin Florentine: Let's do that.

Jannik Luhn: Alright. I can also share my screen, maybe. Yeah, so… I mean, the basic, proposal, is already old, The idea is to let the Validator set whitelist, or allow list, Some key publishers that they, deem trustworthy. And then the question is how to concretely implement this, a long listing process. We need some sort of voting mechanism. And I initially treated it as a black box, which was… yeah, maybe good in the beginning, but not good enough, because there can be, like, details there that are problematic. So I came up with one proposal, I'm not sure if it's the best, or if there can be other proposals, but maybe something to get the discussion going.

Basically, what we need is a protocol where the validators can vote on addresses individually, so each address will be voted on individually, and when it receives 50% support of the validator set. For example, in total effective balance, then it should get accepted by the protocol, basically. There are some softer…

Justin Florentine: So let's elaborate on what we mean by an address, right? This would be a signing address, right? So this would be an entity who we trust to have revealed the key, and their signature checks out, yeah?

Jannik Luhn: Yeah, that would be identity of the key publisher, basically.

Justin Florentine: Great.

Jannik Luhn: Yeah, and requirements, software requirements, it should be efficient, of course. I think there's potential to make these protocols very inefficient, because there's lots of Validators, and we need to count their votes very frequently, so I think that's, an important configuration. We also want to support delegation, because most validators, especially, like, homesteaders, they probably don't want to Make this, choice, and they also have to update it when they notice that some… a key publisher is behaving, like. showing some fishy behavior, so, I think delegation is important.

Justin Florentine: So, can we just, we just… elaborate on that a little bit, right? So, like, the assumption is that I need to delegate out my, audit and curation of this list, right? Like, so, like, I'm not gonna trust myself or take the time myself to actually track all of the, you know, keys that were delayed or never, ever released in order to maintain my own list. So I may want to delegate that out to somebody else that does a good job of holding people that fail to release their keys accountable.

Jannik Luhn: Exactly. I mean, you might want to do it yourself if you're, like, a radical Homestaker, but in practice, you probably, or many probably want to delegate it to someone who is Yeah, better knowledge, who observes what they do, who maybe has, yeah. a special, a special, View of the network, And as you said, maybe even, like, slashing contracts or something like that in place, Yeah, it was just better position to make these, these decisions. And responsiveness, ideally, should be very quick if, if the preferences of the value dataset changes, who… Is a good key publisher and who isn't. This preference should, be translated very quickly into, yeah, the set that the protocol then chooses. And of course, since it's a voting protocol, it should be representative.

in the proposal that I have, it's the full value data set, so it's, by definition, I guess, representative. You could imagine, that you also, choose a subset, Which might also be fine. Yes, and for the concrete implementation, I chose to do the bulk in a voting contract, so on the execution layer instead of the Consensus layer. I guess you could also do it in the Consensus layer. The reason why I chose a contract is because it's You don't have to worry so much about, Spam, because you have transaction fees, in place already. I guess it's also easier to specify, because you have the language of solidity, you don't need to define, like. Networking and stuff and so on.

yeah, I had another reason that I can't think about right now. Mmm… and what this… contract… oh yeah, the other reason is that it's, kind of independent of, So I thought one thought I had, that we could attach these messages, these voting messages to, for example. block proposals or to attestations, but then that clashes a little bit with the responsiveness, because then you can only voice your opinion when you have to propose a block, for example, which takes time. And in a working contract, that's, like, completely separate. It does have downsides, though. Because now a Validator needs to have, for example, to send, send transactions. But, yeah, I guess it's a trade-off. So what this contract does, it does, two things, mostly. One is it manages, ballot lists, like, lists of these addresses that gets accepted.

And that's a permissionless thing, so anyone can propose these lists and edit them, and… Yeah, transfer ownership of them, and that's basically the delegates. The delegates who manage these lists. And it… the other, functionality is that it provides a function where Validators can publish, their statement that they now are subscribed to a certain, list, and they follow this list. Even if it gets edited, they, follow it. So, yeah.

Justin Florentine: We're using terms like ballot and list, kind of interchangeably, and I want to make sure that I'm understanding them correctly. the list.

Jannik Luhn: Yes.

Justin Florentine: is a list of key publishers, yeah? See, I'm thinking of that as a ballot. A ballot is, like, I vote for these people to be credibly neutral to release their keys. Is that correct?

Jannik Luhn: Yes, that's correct. It's basically the same thing, I guess. I'm not sure if… Okay. But distinguish, yeah.

Justin Florentine: Yeah, it's just a writing thing, we can tighten that up. I'm a big…

Jannik Luhn: Talk soon.

Justin Florentine: model guy, I'm big on using a word that's kind of well-defined and resonates with people. Unfortunately, I am a native English speaker, too, so I have a lot of biases there.

Jannik Luhn: Yeah, no, it's good to have these biases, especially from native English speakers. I guess ballot I chose because it came from the, kind of, the voting, aspect. List is the implementation. Yeah, it is more concrete. It's also unordered, so it's not, technically, like, a linked list or anything, it's just, I guess, more of a map. But that's an implementation detail. Yes, I'm not sure if it… I mean, I only specified the interface, I guess the rest can be life-coded, Theoretically, I haven't implemented this yet. We could, in order to prevent spam, require key publishers or addresses, basically, to deposit some ETH before they can be added to a list. And because the number of, addresses that exist,

yeah, reduces the efficiency of the protocol, I guess. And, yeah, these are the… this is the SSV format now, how a, validator would And also the follower list, so… Yeah, very simple message. And then the second part of the proposal is the tallying, so how to actually, calculate the, yeah, the outcome, which, based on these events that are emitted by the contract, how do we get to the list that we accept? And the important thing that I had in mind there when I came up with this is to make it incremental, so that we don't have to, at every block, recalculate everything. But we only, start with kind of a zero initialization state, and then we process, the events one by one.

And… yeah, this updates our, our list. like, the eventually accepted list. And that's, I think, works very well, efficiently. The only thing where it becomes, yeah, inefficient, I guess, is when we have to refresh the… voting waits. So basically when the, Effective balances of the Validators change, of course, when we have to update everything, basically. But what we get in the end, I think that's… basically unavoidable, I don't see a way around that. But what we want to get in the end is, Basically, yeah, the totally effective balance of, That has voted for each individual address, and then we select those that have more than 50% of the effective balance. Yeah, that's, like I said, the brief overview, I'm hoping.

Gottfried Herold: I mean…

Jannik Luhn: I'm hoping that was somewhat understandable.

Gottfried Herold: Interesting. I mean, in theory, you could avoid it by subsampling a random subset each… after each… After each, basically, epoch or whatever, just to only tally from a random subset or something. Because if you want to have a 50% anyway, I mean, typically, it might be okay if you just do, basically, a sub-selection.

Justin Florentine: So…

Gottfried Herold: with that.

Justin Florentine: Let me, let me push back on that, and you can tell me, remind me that I'm not a cryptographer. Why should we use the effective balance at all? Does… does somebody who has more of a stake in the network… have more interest in ensuring that keys are revealed correctly. I don't see an obvious correlation there, do you?

Gottfried Herold: No, I mean, as a cryptographer, if you ask me as a cryptographer, no, but as a mechanism design, the problem is, if you don't do that, then, consolidating balances becomes, basically reduces your voting weight, and this is something we do not want to incentivize.

Justin Florentine: I see. Anders is making a similar point in chat. Can be gamed by splitting up stake, yeah.

Gottfried Herold: I'm safe.

Justin Florentine: Yeah, we disincentivize, yes, we disincentivize consolidation. Okay, good point. Great.

Jannik Luhn: For sampling, I think that's interesting. I guess you have to… I don't know how big the effective balances differences are, if there can be a very big validator that has, I don't know, 30% of stake, like Lido, if they have every stake, everything in one address, you want to make sure that you count it.

Gottfried Herold: Yeah, I mean, you could instead just sample, instead of waiting, you could basically sample. Instead of basically waiting, you could basically just sample by weight, which is something we do anyway. Yeah. And then… and then weigh normally.

Jannik Luhn: What you could also do is you could count, like, this is just counting them unorderedly, you could, start with the biggest validators, and then stop once you've reached 50%, and you don't have to count the rest. If one has zero votes after counting 50%, then you know they can't ever get over 50% again.

Gottfried Herold: Yeah, me that… point is, I think this… might not help you too much, because you would… you would go over all the validators, update, basically, your… your IDs, and then after that is done, you go over the IDs. It's just much more efficient to do it that way.

Jannik Luhn: I see, yeah.

Gottfried Herold: So this doesn't… this optimization doesn't really give you that much, unfortunately.

Jannik Luhn: I guess in the end, it's an implementation detail, and what would be interesting is to have a benchmark of that. I don't know how… How fast this, currently is, how… How fast the motion mechanism would be.

Gottfried Herold: I mean, basically, it's… I mean, you have to update something, you have to update something that is sort of in memory, you have to do basically the same course as updating all the Validator balances once, just to update the weights for each of these lists once, and then you go through over all the lists.

Jannik Luhn: Yep.

Gottfried Herold: I mean, I expect that there is not too many lists, so the first part is sort of the… should be dominating.

Justin Florentine: Okay. So, I guess, with regard to list count, and I think… Gottfried, you kind of alluded to this in some asynchronous comments. The costs of voting, right? Like, how… does it cost something to vote? Should it cost something to vote? There's an open question of, do we want to do this across the entire Validator population, or a subset? Is this a majority? And we also have 50% in there, right? Is that the right number? Is there maybe a plurality, that… that is required? Is it a supermajority that's required? You know, there's… there's… 50% makes intuitive sense, but I want to kind of explore maybe if there's other reasons to do that. Yeah, so I guess those are the three questions I have. I mean, let's just start with cost to voting, like.

What are the costs That are kind of intrinsic to doing the voting. Do we need to reward people for paying those costs? Or do we treat this as, this is just a duty of the network, like, you have to, you have to do this?

Gottfried Herold: I mean, the way that design currently is done, it's essentially… it's a contract, it's a transaction, so you have to pay for, basically, for a block space, that is there, for the, for, The problem I see is that if you don't make anyone pay for it, you basically create, basically a free block space.

Jannik Luhn: Yeah, I think it goes in both directions. If you make it free, you get free block space, and you could spam the chain, potentially. If you… You could also argue you want to pay them for doing so, because it's work that they have to do, but then it's, like, unclear how much you should pay them for. It's also unclear how many, like, the protocol doesn't know How often a validator should vote, because it depends on the behavior of the key publishers. So, I think that's very, very difficult to, yeah, to come up with a good mechanism there, and I think just… Yeah. I guess it's not a good answer for, for cryptoeconomics people, but I would just…

Keep it as is, and hope… People are honest.

Gottfried Herold: I mean, of course, you could always record the blockade at which, sort of, your given Validator last voted to, sort of, limit and to rate limit things, so… This kind of spam, that somebody abuses it for free block space. What, yeah. I mean, my expectation would be that, I mean, you could always say, hey, if… I mean, essentially, the entities who do the key reveal will be economically incentivized centralized entities, and they could just say, hey, I'm going to pay something for everybody who voted for a list which included me in this In this timeframe or something. Or with frame Transaction, they could even sponsor it.

Jannik Luhn: And that could even be done trusted… trustlessly using… Exactly, exactly.

Gottfried Herold: So, basically…

Justin Florentine: Wait, could you elaborate on that? I'm not sure I followed the… I said, could you elaborate on that? I'm not quite sure that I followed that. Like, I get how you could use… Frame transactions to do it trustlessly.

Gottfried Herold: What do you mean by trustlessly in the first place? I mean, you could, of course, make some contract that basically… that basically some Paymaster contract that pays for any such transaction that basically votes… includes a certain, key publisher address.

Justin Florentine: Hmm.

Jannik Luhn: I mean, you don't even need frame transactions for that, you can just have a bribery smart contract somewhere else that pays everyone who voted for me, a certain amount of money, maybe even only if I get accepted in the end.

Gottfried Herold: The problem is just to make sure that you don't vote for something else, or you don't vote a second time, or that this kind of.

Justin Florentine: Yeah… ugh. On-chain voting is, like, playing with fire, man. This whole thing is… Spooky.

Gottfried Herold: I mean, generally, I think it might be a good idea to sort of record the time when you last wrote it in the system contract. If you want to sort of, incentivize such solutions, just to sort of help them Prevent certain forms of abuse. Because otherwise, they would have to record it. And each of them would have to record it. On their own.

Justin Florentine: So, we're, we're… hmm… We are requiring decryption keys to be, you know, signed from the allow list, which means this entire mechanism is actually in protocol for its users, right? Like…

Gottfried Herold: I mean, the CL needs to know it, it needs to get exported to the CL, and we basically just don't accept… Elusive Transaction… If the, key population that is recorded there is not in the list.

Justin Florentine: Yep. Anders, you're referring to the original shutter design that had the trust graph sort of thing in the front. of… on… Yeah, the trust graph that was kind of based on the ordering of the transactions on top of block, right? Yeah.

Jannik Luhn: But that was not enough. Like, some people, criticized that you could still… Like, even if… like, not… use the optionality, not the background. Other transactions, but you just… I don't know, some weird, arbitrage transactions.

Justin Florentine: So it diluted the optionality, but didn't mitigate it.

Jannik Luhn: Yep.

Justin Florentine: It's not severe enough. Hell yeah, the builders don't like that. Hmm… Alright, sounds like this is complicated. Shocker. Do we have any other points that we want to cover? Do we want to continue to dwell on this? We're at about the halfway mark. Time-wise.

Gottfried Herold: I mean, as I said, I mean, the 50% is, of course, something that is completely arbitrary, and basically any kind of threshold works. You could also make it… more dynamic, if sort of the vote splits very, very strongly, that you might want to lower it dynamically. I guess 50% is just a shelling, a natural shelling point. It's kind of a neutral, kind of unopinionated. Sort of… It's basically an unopinionated neutral shelling point, which is good and nice. But there is nothing in the design that enforces it.

Justin Florentine: So, when we, when we talk about boats. Do we want to, you know, treat it kind of like, you know, the presence of a vote is an endorsement and the lack of one is an abstention? Or do we want to actually have upvotes and downvotes? Meaning, we should downscore this person because I think I caught them withholding a key. Or is that a distinction without a difference?

Gottfried Herold: I mean, you can always vote for an empty list, basically, to explicitly abstain. So…

Justin Florentine: Hmm. Right.

Jannik Luhn: I mean, you could argue maybe some validators have, maybe I don't want to vote because I have no opinion, but maybe some validators have strong opinions that one key publisher is Doing bad things, then that we might… Give them, like, more negative thoughts, in a way. Oh. But, to be honest, I think I would keep it as simple as possible.

Justin Florentine: Yeah, I'm kind of thinking that, too.

Gottfried Herold: Yeah. I mean, the question is just whether you sort of make the tallies, or the 50%, basically among the total, weight of all… the total balance of all validators, or just among those validators that have voted. Because if you make it among the total validators, then if participation into this mechanism is sort of low, then you basically get no key publisher at all, and that would be kind of a bad outcome.

Justin Florentine: Wait… So, for instance, a regional outage, right? Where the attestation's, you know, weight goes down, or something like that. You lose Ability to reveal keys, right?

Gottfried Herold: That is kind of… that's not a problem. The problem is, okay, so let's say we have some kind of fork where this feature goes live, but sort of… a lot of validators just don't bother with it, and they just don't do anything. then, well, basically, we have zero registered key publishers, and nobody can send any Lucid messages, and we spend a lot of effort into enshrining a feature that is actually completely unusable.

Justin Florentine: Yep.

Jannik Luhn: We could also make the threshold dynamic in principle. And let the Validator set vote on the threshold as well, similar to how they vote on gas limit. Can they still do that? Let's still Work 2, at least.

Gottfried Herold: That's a good point. And just to answer Anders' question on the chat, I mean, since this is, The point is… the point of this mechanism is that actually, the attestation is basically a block, with a… which includes, or, a, a Lucid transaction which uses a key revealer that is not in the list is actually invalid. That's basically the enforcement mechanism. Because if you could use Lucid transactions with, sort of, key revealers outside of this mechanism, you run into the whole enshrine… the whole, problem again. Or you mean you just use those, sort of, from the enshrined ones on top and below, sort of, the ones from others?

Justin Florentine: Oh. Oh. Hmm, okay.

Gottfried Herold: Hmm.

Justin Florentine: So you order your top of block by… People that have… Key providers that have been… Vouched for. And if you don't, you're at the bottom of the top of block. Yeah, yeah, yeah. Huh.

Gottfried Herold: Yeah, it does kind of protect against certain forms of bad MEV. I am not sure about, sort of, these kind of self-revealers who sort of want to, sort of. Yeah. Decide not to reveal on their own.

Justin Florentine: you're still…

Gottfried Herold: You're able to read.

Justin Florentine: Front-run the remainder of the block, just not the other people that are participating via a trusted key revealer.

Gottfried Herold: Exactly.

Justin Florentine: It… it is not as bad, and it does drive… it does drive… drive people to use it as well, right?

Gottfried Herold: just feels like a bit… just feels a bit, I don't know, half-baked, you know?

Justin Florentine: Feels like a half measure.

Jannik Luhn: On the topic of the threshold, it should probably be higher than the biggest staker we have right now. Otherwise, one big centralized staker could get in a key publisher. Just purely on their own.

Justin Florentine: Refined.

Gottfried Herold: That's a good point.

Justin Florentine: Sure.

Gottfried Herold: Maybe you should also allow negative votes and count those double or whatever.

Justin Florentine: Yeah, negative voting introduces more motive. I'm voting… upvoting this person because they have a track record of being trusted, and I'm downvoting this person because… their stake is too big. Those are, those are two different… Intent… intents that are being captured. Still don't think it's worth the complexity. Hmm.

Gottfried Herold: Yeah, I guess 50% of all stakes are kind of a reasonable shelling point.

Justin Florentine: Yeah, I think that's a good starting point. Okay, I'm gonna capture this idea about… Top of block ordering. So, top of block ordering can be used to prioritize… The use of… Who allow listed providers. Over. Unknown. ones. Which also asserts that we don't… we no longer reject the… we don't actually check the list. Well, we check the list when we're prioritizing top of block.

That's the only time you check it. Okay. Incremental improvement.

Gottfried Herold: I think it would also sort of alleviate, sort of, these, market entry barrier issues that I think are basically the most… Are my main concerns, actually, with this.

Justin Florentine: How does it alleviate them?

Gottfried Herold: Because you can still… I mean, okay, so let's say you are some kind of provider.

Justin Florentine: Yep.

Gottfried Herold: who does this, and who does a good… I mean, you are basically a financially incentivized entity who does basically do this kind of key reveal service, and of course, you collect fees for that, you have a lot of expensive infrastructure and everything, and now your approval rating among the… Validators, basically is like, I don't know, 51%, mostly because Lido got bribed by your competitor, who wants you to go out of business so they can take over your share. Now, you basically go from 51% to 49%, and one side of a sudden, all your revenue goes down to zero, and you go bankrupt. And on the other hand, sort of, if you're sort of a newcomer who wants to sort of enter the market, you basically can make zero revenue until you hit the 50% mark.

And that's actually quite a high market entry barrier, because you have to upfront a lot of investment to actually convince people to read to get your 50% before you make any benefit. It's basically this kind of, sort of a bootstrapping problem to actually get into the market.

Justin Florentine: Damn.

Gottfried Herold: And if you allow those Even before, just not in the top of blog section, you can actually have an opportunity to get some track record, and you still get some revenue, even though.

Justin Florentine: Maybe less people are using.

Gottfried Herold: you, but…

Justin Florentine: Even the voting set could promote people from, you know, that bottom of the top of the block to the top of the top of the block, effectively.

Gottfried Herold: Yeah, I think it's only two tiers, I mean, it's only two tiers, not… don't rank by, don't drink by, sort of…

Justin Florentine: No, no, no.

Gottfried Herold: Because we already have a mechanism for the top of… Block ordering, but, yeah. You're much less vulnerable to, sort of. These kind of games where people sort of… where your competitors sort of basically vote on whether you should be able to participate in the market.

Justin Florentine: This is a fun idea.

Gottfried Herold: Oh, yeah, I quite like… actually, I quite… I started to like this, sort of separating… The top of blocks section into too much more.

Justin Florentine: It's not quite the trust graph idea, but it kind of smells like it.

Gottfried Herold: Yeah, it gives much less restrictions. I mean, the problem I have with the trust graph is that it's sort of super, super restrictive, and you have this complicated graph, and you have to basically satisfy a lot of constraints. Which, most of them, you don't really care.

Justin Florentine: It prescribes a lot of.

Gottfried Herold: Yeah, yeah.

Justin Florentine: up top of the rock.

Gottfried Herold: Exactly, and here you just have one bit, essentially. Which is kind of okay.

Justin Florentine: Neat. Okay. Alright, AI, take a note. We are excited about this idea and want to pursue it further. Now, I don't want to overthink it in the moment, but we do have some time left, so we can keep going, we can put a pin in this… We've got 15 minutes left…

Gottfried Herold: Cheap.

Justin Florentine: I wouldn't mind circling back and doing some more thinking and writing on the matter. I think Anders and I are probably about due for updates to the EIP, I don't know that we've made any… Changes to… cover this idea of the allow list at all. We certainly haven't done any of the, you know. Stuff we talked about today,

Gottfried Herold: I mean, the question would be even whether there should be one EIP or two EIPs.

Justin Florentine: Yes, thank you. I was thinking that too, I didn't know if I should bring that up. I think now that we're kind of circling back to using the top of the block to prioritize it, it's less warranted as its own… EIP, but what do you think? EIP itself is pretty big.

Gottfried Herold: EIP is already pretty big, and it means splitting it into basically the EL and CL part might also be nice, because essentially the voting… most of the voting is sort of on the EL side.

Justin Florentine: Yeah, but you can't ship one without the other, really.

Gottfried Herold: You can't ship Lucid without the other.

Justin Florentine: Okay, yeah.

Gottfried Herold: Yeah, there is… There's actually… Yeah. Yeah, just if you sort of have some time. There's just two things I just wanted to mention briefly, maybe unless I forget them. One is that, just because you're sort of talking about updates to the Lucid EIP, don't forget that, I think one of the hashes in the Lucid EIP basically needs to get some randomness into it. Otherwise, oh, just don't forget, just as a reminder for the AI, please record that, because one of them needs to be hiding… one commitment there needs to be hiding. Check that, just more of a reminder to the AI. The second question is, I mean. Currently, the current design of Lucid has some rather large penalties already, financial penalties, and, for not revealing your keys. I think it's 128-fold penalty. Basically, they get some kind of refund if you re… if you release some key, if I remember things correctly.

This is a bit bad at the moment, because it requires you to upfront some capital to make a transaction. And if you have some kind of allow list-based thing, you might be able to lower that, which would make the whole thing more usable, I think. And that was a bit less risky for the users. I'm not sure, maybe, Anders, what you think about sort of lowering the contents there, if you have some kind of other mechanism to, sort of, prevent this abuse, just for usability? Let me check the EIP, what I mean exactly.

Anders Elowsson: See if you hear me. Do you hear me? Yeah.

Gottfried Herold: Yeah, you're extremely silent.

Anders Elowsson: So… If we do this split between two different, things, then I think that the Lucid can stay as it is, or at least, I don't know if we necessarily need to have, This 128 setting, but a way to reserve a large amount of, funds that you then are returned. But the thing is that in the Lucid design, we just described that you don't necessarily need to do that as the sender of the transaction. Because the key publisher could facilitate that for you. Awesome. I think…

Gottfried Herold: Yeah, it's just a question.

Anders Elowsson: If I remember.

Gottfried Herold: Whether even… yeah, that's true. The question is just whether it's even necessary from the… from the onset. Just also make it easy, because you now have kind of two mechanisms doing the same kind of thing.

Anders Elowsson: Yeah, but, okay, yeah, maybe, but I'm thinking that if we have this whitelist, and if you send to a key publisher that is on the whitelist. Then, it seems that you… Can you skip your… top-of-block feels rather small anyway, right? So… I don't know, I remember there are some nuances around this anyway that isn't really worked out. I mean, 128 sounds big, but if you… you can still keep it very small, because you can have it very small. So it's…

Justin Florentine: And, correct me if I'm wrong, I forget where we landed on batching, Anders. Does that fee get amortized over a batch?

Anders Elowsson: Yeah, I mean, the Lucid EIP right now has batching, right? But we… and you pay as a batch.

Justin Florentine: Right.

Anders Elowsson: But we are thinking that patching makes things very complicated, so we are not so super sure about having this, bundles.

Justin Florentine: Bundles, that's the term, thank you. Hmm. I do find the argument that, you know, the key providers are maybe a little capital-intensive anyway. So they can, they can handle this, this fee. I do find that kind of compelling.

Anders Elowsson: Yeah, yeah, I think that, if I remember correctly, there, it was, Outlined how… how that could, happen. But I think that was in the bundle design, maybe. I'm not sure. The EIP describes how it's going to be done in the bundle design. Anyway, concerning the split of the EIP, yeah, we should… for the whitelist, yeah, I think it's probably, in either case, probably best to start Working on the whitelist as its separate thing, because you have to work out a lot of things. then it can be its own EIP, or it can be combined, But I guess you have to work everything out anyway, like…

Justin Florentine: I want to be careful that factoring out into a separate EIP is not premature abstraction. Think about that.

Anders Elowsson: Yeah, I mean, I mean, Jannik could write down, or, like, those who want to be involved could write down, huh? If, like, a PR to the EIP, otherwise, and be involved in… I mean, we should probably… invite these people to the EIP anyway, so… It's… we can just… It doesn't matter to me which way it's done.

Jannik Luhn: I also don't think it makes a lot of difference if it's… One or two documents if they… Go together anyways.

Gottfried Herold: No strong opinions.

Justin Florentine: Yeah, let's keep it one dock for now. We can always break it out later if it really does get unwieldy. I think, I think there's some, some things in the, in the EIP itself we can maybe tighten up and trim up. To, to, to make some, make some room for this. Do encourage you, though, to, Jannik, to, open a PR into it. We'll get you on there as an author, I think.

Jannik Luhn: I guess it still needs some work to be actually part of an EIP.

Justin Florentine: Yep. But it sounds like we like this idea, it's worth pursuing. Let me be specific. A whitelist of the key reveals. Key providers, right? Including them on top of block, ordered by whether they… are on that list or not. We still want to allow for non, you know, you know, keep self-reveal. We still want to allow for self-reveal. Awesome. Feels like a good place to put a pen in it. Great work, everyone! I feel really good about addressing optionality. Nice find. Nice find. Cool, alright, well, stay in touch on Telegram, and yeah, keep your eyes peeled for PRs.

into EIP 8184. Talk to you later. Talk to you in a month. Bye-bye.

Jannik Luhn: Bye-bye. Thank you.

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