All Core Devs - Consensus #183

Transcript

Parithosh Jayanthi: Hello, everyone.

Justin Traglia: Good morning.

Parithosh Jayanthi: Let's give people another minute to join, and then we can stop. Okay, let's get started.

Can we get a confirmation that we're live?

Akash | ECH: Yeah, we are lying.

Parithosh Jayanthi: Alright, thank you. First item on the agenda is DevNet updates. We had DevNet 7 launch, late last week, I think. Could we get an update from Stefan?

Stefan Starflinger: Yes, sure. So, DevNet 7 has been going through different kinds of testing. One of the most recent ones that we are experimenting with is withholding payloads. From the builder, so a lot of the blocks have been, orphaned. And we've noticed, quite a few different issues, as well as, the builder has been, Patched in a way that it overrides the gas limit header, which has caused some issues today. In general, we noticed that the PTC votes for blobs seem to be, not considered if the payload isn't there, and the PTC vote for blobs should always be considered as a liveness check, independent of the payload. I think that's something that clients are looking into. Now, and otherwise, we have quite a few bugs across the board and improvements that we've…

Posted, in reports. It would be good to maybe get some feedback if the reports have been helpful in the way that they are presented, or if there is something that we can do to improve them. In the future, as well. I don't know if you have anything to add, Perry.

Parithosh Jayanthi: I think the main thing to add is that we've been using two tools so far. So we have the builder itself, where we can delay some payloads, and the other one is TISM. I think TISM's scenarios have laid down in the Steel Discord. it seems like we're causing more issues with Builder than with Prysm right now… with TISM right now, but, yeah, mostly intrigued to hear from client devs how the debugging is going, and if anything useful was found in the last days. Terence mentioned they found some Beacon API performance issues.

Terence Tsao: Yeah, we found some issues that builders were not actively trying to delay payload, but we received a payload late. Which is a little funny, because, it uses Prysm to propagate the payload, to broadcast over the network, but we had a performance issue such that even though it released on time, it still took 2 seconds for them to propagate it, and it showed up late, so we were able to fund that.

Parithosh Jayanthi: Nice. Did someone from Prysm have a chance to have a look at the double vote issue?

Terence Tsao: I just saw it, I have not.

Parithosh Jayanthi: Okay, yeah, any other client teams? Anything worth mentioning from debugging efforts, or are people just basically heads down with still… Triage unions.

Enrico Del Fante: I have a question. about terence, what terence just said. Is, is the delay only, seen from… Prysm API, or there are other builders publishing using different A bigger node that doesn't have the same issue?

Terence Tsao: Yeah, so to clarify, there was 3 builders total, and the only builder 0s, based on our, categorization, we look at all the logs, only in builder 0 are, are sending payload apparently revealed on time. But PTC sometimes voted majority late, but builder 1 and Builder 2 are always on time, so it turns out Builder Z… so that was a clear pattern, that only builder 0 had the issue, and builder 0 was only using, recent Beacon API implementation to propagate, payload.

Parithosh Jayanthi: Nice. Anything else for Glamsterdam DevNet 7? Has, since we have the SSZ changes in, has anyone noticed any degradations in performance, or anything else worth mentioning? With progressive stable containers? Okay, cool. The next item on the agenda is, Glamsterdam… yeah, terence?

Terence Tsao: Regarding stable container, we only have 3,000 active validators, and typically validators are the heaviest part in the Beacon state, so maybe it's not too… maybe it's not enough to see if there's, like, such perfume bottleneck with changes like stable container, right? We probably want to ramp the Validator kind of up and check again. we have… Yeah, yeah. I do mean the AC Validators, yeah. Oh, I see.

Parithosh Jayanthi: exited already, so we started doing this trick where in the Genesis state, we just shove a ton of exited validators.

Terence Tsao: Okay, maybe we should let this run longer then, because I do have… Front jobs, they're actively capturing profiles. And so far, it hasn't been any bottleneck, but maybe I didn't capture them at the right time, when there are tons of validators in there. So maybe keep it longer or something.

Parithosh Jayanthi: Yeah, okay, sounds good. Also, DevNet8, we can just have more, active validators as well. Yeah, next item on the agenda was, regarding the Beacon API changes that was brought up on ACDT on Monday. Can someone summarize the discussion or current status? This was about Beacon API changes to produce block V4, as well as the key manager API changes, like, the whole topic in general.

Jason Vranek: Hi, I've been working on, yeah, 3 of those PRs, also for the builder API, just to keep them in sync. I think there was some sort of divergence, and yesterday, some clarity around, Adding proxies as more of a first-class thing, and removing that, and… As of last night, the PRs are all updated to remove those. I think what isn't added to it yet is discussion… there's been discussion around, The timeouts and the headers and, default values for the clients, which I guess wouldn't make it into… the headers would make it into the builder API, but the defaults would be up to the clients. But I think there's been a lot of node operators, like dbt teams, looking at the specs, but I don't think there's still rough consensus.

Parithosh Jayanthi: Okay, nice. Is there, anything other than just a bit more… Time required for rough Consensus to arrive, or is there a specific blocker, by any chance?

Shane Moore: I mean, from a SSV side, as one of the dbt clients, we at least checked out the six… 25 PR, and we're compatible with that, so happy for it to merge or whatever. Then, yeah, Jason's PR for, like, 6.30 would be also great to get more client teams looking at it. We're basically adding, like, an ahead-of-time submit builder preferences Beacon endpoint. And that would be cool for, dbt clusters, so we can do our, like. threshold signing and auto submission for this new request off V1, like, an epoch before the proposal, like, before the block proposal. So, that way, you know, it gets off of the hot path, which would be, you know, nice. I think so far.

Let's say Losar and I think Prysm have taken a look at the 630 PR, but yeah, if we get more client teams on it, that would be great as well.

Parithosh Jayanthi: Nice, thank you. Yeah, I see there's a ton of discussion going on on the EPBS channel, so if anyone's interested, then please chime in. I think the relevant parties are mostly DVT providers, anyone relying on the Key Manager API, and so on. And yeah, for… to Terence's point, maybe the soft deadline can be Monday, where we would merge in all the changes, let's say latest at ACDT, so we still get some synchronous time, and then we can merge immediately after. The main reason for, let's say, Monday as the deadline is that once the mergers are done, clients can work on implementations, and we can target DevNet 8 the week after. Does that feel like a reasonable timeline?

Okay, Yes, and Nico's question is about the circuit breaker. Do all clients have circuit breaker implementations? Maybe could we go client by client and just talk again about where you guys are on implementation? Do you want to start, Nico?

Nico Flaig: Yeah, I think our implementation is pretty much finalized. We had some more discussions, for example, if we should consider only our canonical branch or all branches. So right now, we consider all branches and track missed payloads there. Yeah, but it's pretty much final, it's already on devnet 7. So we are just ironing out some few details.

Parithosh Jayanthi: Okay, great. Anyone from Prysm?

Terence Tsao: Otis was just looking at it, I think he just joined. So, Otis, any updates on the circuit breaker?

Potuz: Oh, there is… there is… no, on the Rakuten node, on the DevNet, yes, there seems to be some peering problem again. Just a simple restart keeps the nodes in sync. But, for some reason, and it's hard to see why. We were isolated because there's a lot of invalid payloads floating around. But yeah, Prysm nodes, fell out of sync when they were just isolated and they couldn't just sync anything because they didn't have any peers, and just a simple restart, like. makes them catch up quickly. So, it seems to be, again, just a peering issue. I do… I haven't found the reason why we are downscoring our peers, but it's gonna be hard with all these invalid payloads.

Parithosh Jayanthi: Okay, that's fair. Thanks for the update, and yeah, I guess circuit breaker implementation stuff will… would it be done by DevNet 8, or what's the plan?

Potuz: Yeah, yeah, yeah, it should be done. I'm sorry, I'm delaying that.

Parithosh Jayanthi: Okay, cool. Do we have someone from Teku, Enrico, or someone else?

Enrico Del Fante: I'll leave it to Mehdi, who is… who implemented it. Maybe it's not… It's still in mute. I know we merged the… we merged the PR. I don't have specific details, so… yeah, we have something, I don't have much more details.

Parithosh Jayanthi: Okay, nimbus? Do we have TerSec, or Etown, or someone else?

Dustin Brody: Yeah, Nimbus does… I mean, we have our, our Fusaka, of course, version, but no, we do not have something yet for Grandine. It's, the, priority.

Parithosh Jayanthi: Okay. Lighthouse? Okay, I don't know if someone from Lighthouse is on today. Grandine, is there anyone there?

Saulius Grigaitis: Yeah, we also don't have an updated version for the… for the glass. We only have this previous Fusaka version, so we will work on that at some point, soon.

Parithosh Jayanthi: So I guess that we should add it to the spec sheet for DevNet 8, so that we have Beacon API changes, and hopefully, separate breakout changes as well before we launch DevNet 8. Okay, any other builder API and or Web3 sign-up ERs to be discussed? Great. I did want to leave a note that, Toni has a message on the Block-level access list channel, mainly flagging it because there's some EnginePI changes. I don't necessarily think CL Devs need to engage on anything there, but… Probably worth keeping an eye out. And the last item on the agenda for Glamsterdam is, on ACDT on Monday, there was intent from the testing teams to SFI all the EIPs that have been at,

That, been included in devnet 7. Is there any objection to this? Okay, if that's the case, then we'll go ahead and start creating the EIPs to SFI the EIP. Yeah, we'll go, create the PRs to SFI the EIPs. Anything else Glamsterdam related?

Stefan Starflinger: I created the DevNet 8 spec sheet. I shared it again if clients want to have a look, or people want to give some feedback.

Parithosh Jayanthi: Perfect. Thank you. Yeah, I think timeline-wise, we're still looking at DevNet 8 early August. We would want at least one public-ish DevNet, and a non-finality DevNet, both ideally in August. And that should still allow us to potentially have the first testnet in September. Just to have a view on… In the know about the timelines we're trying to target, at least. Okay, next item on the agenda is, Hegota. Do we have Sukun to talk about, bundled attestation propagation?

Sukun Tarachandani: Pike.

Parithosh Jayanthi: Hey, yeah, you have the floor.

Sukun Tarachandani: Yeah, so I have the EIP. I have linked it in the… issue. I'll share it here in the chat. And I also have consensus facts related to it. And I have a draft implementation in Prysm as well. So, I basically talked about it a few ACDCs ago. The idea is to deduplicate attestation data, and so… to save bandwidth. This helps in the future with decoupled Consensus a lot. And, the nice thing here is that, basically, I've kept all the changes to a minimum, so… because anyway, the objects that we vote on will change for decoupled Consensus, so… I've not made such large-scale changes. And it should be fairly easy to implement, so I would like to propose it for Hegota, and, like, if people need any other information, I'm happy to provide them.

But otherwise, we can keep discussing on the EIP or the Consensus bits.

Parithosh Jayanthi: Are there any open questions from the clients about this?

Sukun Tarachandani: Not yet. I would like… yeah, basically, I think I have 2 more weeks, so I'd like to highlight it to all the client teams, and they can reach out to me for any questions they have.

Parithosh Jayanthi: Okay, perfect. Any immediate questions from clients, or should we move to the next topic, then?

Sukun Tarachandani: Also, just to highlight, like, the change itself is backwards compatible, so… This does not need to be fork color. the post-k-out fine.

Parithosh Jayanthi: Nice. That also probably implies we don't need to necessarily ship this at a fork, right? If some client implements it beforehand, yeah.

Sukun Tarachandani: Yeah, yeah, it is fully backwards compatible, and it really should not impact If a client ships it before, also, it should be fine. So, it follows the same thing as the data columns work that we did. And, like, yeah, so that would also… we would also get some… Sort of confidence on the partial messages system by then, when we ship data columns.

Parithosh Jayanthi: Yeah, makes sense. And yeah, like Daniel mentioned, I guess we can make it required for, Hegota if we do intend to ship this, so that, worst case, we know on the networking level, everyone has it post-star.

Sukun Tarachandani: Yeah, awesome. Awesome.

Parithosh Jayanthi: Cool, yeah, please engage on the EIP if you have questions.

Sukun Tarachandani: I will also share the consensus bits, so yeah, look at the comments there as well.

Parithosh Jayanthi: Thank you. Anything else on this topic?

Daniel Knopik: Yeah, quick question from my side. This basically supersedes Roel's earlier proposal of, batching attestations at source, right?

Sukun Tarachandani: So that is an orthogonal change. If we do it, we'll have to change some of the data structures that we use here, but you can use both of them in conjunction. So, if you batch at source, you can still use this with the… there are orthogonal changes. Well, that's technically what Raoul's proposal was doing was pre-aggregating at source, and what this does is it just makes the network data structures more efficient, so that we save bandwidth.

Daniel Knopik: Yeah, I'm just wondering if there's still value to batching at source, if basically everyone can at least bundle them, but that we can discuss.

Sukun Tarachandani: Yeah, sure. I think that needs to come from simulations, so maybe we can take that up.

Parithosh Jayanthi: Awesome. Anything else? Any other comments or questions from client teams? Okay, thanks. Thanks, Sukun. Next item on the agenda is, partial execution payload commitments from, Toni. Are you on the call to speak?

Toni Wahrstätter: Yes, hello, Perry. Hello, everyone. So, this is a new EIP, I will post it into the chat, it's there right now. And this is an alternative to what I presented a few weeks ago on the… on ACDE. Namely, an alternative to the late-stage route. If you remember, the late-stage route EIP worked, where you basically replaced the post-stage route with the pre-stage route, and every block would not contain the post-state route and the header anymore, but instead you would commit to the output of the previous block, which is put into the header as the pre-state route. So, essentially, the earlier EIP, which was 7862, It's, did the original, the late-stage route, idea, but this new proposal

Does it a little bit differently. Namely, if you look at the EPBS bid today, the bit commits to the block hash, and instead of the bit committing to the block hash, we would now unbundle the block hash, and commit in the bit to all the fields that the EL block header contains, except the state root. This means, Yeah, I guess we'll give people a minute.

Parithosh Jayanthi: Yeah, no idea what happened. I think we had multiple hosts, maybe one of the other hosts leaving, to get the call end?

Toni Wahrstätter: Yeah, it was… it was too much for them. Another delayed-stage proposal. Okay, let me quickly post the…

Parithosh Jayanthi: Just one too many.

Toni Wahrstätter: Exactly, exactly.

Parithosh Jayanthi: Are you just got a little flip.

Toni Wahrstätter: I will post a link into the chat again. So yeah, the second proposal replaces the block hash with the state root.

Parithosh Jayanthi: Hang on for a sec.

Pooja Ranjan: I just need to get my response.

Nixo: Dreaming.

Pooja Ranjan: Yeah, I just want to mention that we may not be able to continue the same streaming, so let's continue recording, and at the end, I will upload the full recording. Or, Akash if you can confirm. I don't think it is possible, like, technically. We can definitely go back and record the entire recording.

Parithosh Jayanthi: Yeah, let's just give them a minute to figure this out before we start back, Toni.

Toni Wahrstätter: Okay, I'm fine.

Pooja Ranjan: I think we can go ahead and continue. We are recording, and after the call, I will collect both of the recordings and upload it.

Parithosh Jayanthi: Thank you so much. Thank you very much.

Toni Wahrstätter: So yeah, TLDR, instead of committing to the block hash and the bit, we would commit to everything in the EL block header except the state root, which means… the builder would include a bit with all the EL header fields, so it's already a commitment to the content of the block, because of course, things like the transactions routes or the receipt routes are all committed in the bid. everything but the state route. So the builder would then have time until he reveals the payload to compute the state route. And this is an EIP, so the idea comes from Francesco from the… from EF ZKVM team. And the goal of the delayed state route EIPs is, of course, to give the builder-slash-the-prover more time to construct the proof.

And we are still in the process of, figuring out, like, which EIP is actually the better one. And I am… I, myself, am not super clear, like, which one we actually want to do. This later EIP comes with no delay for light clients, which is very nice, but at the same time, it wouldn't give you the additional 12 seconds to generate the state proof of the ZKVM. So the ZKVM proof would be split in two logical parts, which is the execution proof and the state proof, and with the original state root, delayed state root EIP, you would have an additional slot for proof generation, at least for the state root part. And with this one, you wouldn't have that. But instead, you would have a little bit more time, because you don't need to calculate the state root for your bit, you only need to calculate it

When you release the payload. And that's basically it. I think there's still more input needed. I proposed the two alternatives, and we would probably only pick one of them, especially because the earlier one, the late stage with EIP, would, consume the later one. And the later one is more like a trimmed-down version of it. And yeah, I'm very happy if there is any question. I saw Etan is asking, what about BlockHash? Potuz is asking something about the SSZ root. Could you guys quickly, clarify?

Etan Kissling: Yeah, just for the block hash, that spans over the state root, so if we remove the state route, we also have to remove the block hash, if it's there, even.

Toni Wahrstätter: Exactly. We would… we would, so today, the state root is not in the bit. The state is implicitly contained in the block hash, you could say, and now we would completely remove the block hash, and instead move all the fields that the block hash commits to in the bit, which means everything in the EL header. would move into the bit, but accept the state root. So the state root would be the only field that we wouldn't replace with the block hash.

Etan Kissling: What about the receipts route?

Toni Wahrstätter: receipts route and transactions route, so the two execution outputs, they would still be in the bid. So you would essentially commit to the contents of the block. But without committing to the state. So everything is deterministic, you can't change anything. And to answer Potuz question, it would probably just be a hash. I guess we could… we could make it the SSZ root. Like, I'm very open for that, but I think we… we can decide that as soon as we decided which variant of the late stage route we actually want to do. If we even want to do any of them.

To answer Etan's question, this is a non-headliner proposal. It should be rather small, especially the one I presented today is, like, super small on the seal. The earlier one was only EL, And is a little bit more, involved, just because it adds some complexity around reorgs, but nothing that is actually, Like, nothing that isn't figured out already. Yeah, potuz?

Potuz: Yeah, I have nothing against the CIP, it seems reasonable to me, but you'll want to have a little bit more detail on the CL side, on how this is going to be validated. I mean, processing the bid is absolutely fine if we have a hash, or if we have an SSZ root. We can just check it. But, we use the block hash On the bid, on implementations, to check when we're receiving a block, if it's based on full or on empty. So, that information now, it's going to be off-chain, it's not going to be committed in the bid. So we will need to modify the paths on how we check if, when we receive a CL block, if it's billed on top of full or empty. Perhaps the easiest

Would be to just add that bit in the bid.

Toni Wahrstätter: Yes, this is a very good point, and I stumbled across exactly this, too. So my thinking was that maybe we could use the… The parent block hash for that, In order to still be able to tell if empty versus full. But just using the bit's parent block hash?

Potuz: Yeah, but making sure… you can always commit to the parent block hash in the bid. That's going to be… I guess that's… you're still committing to it. But the problem is that if you're building on top of full, then the parent block hash is a block hash that is not known from… purely from the CL side. So we will need to get the block hash on the… so I assume that the easiest would be to have an Engine API, that when we send a new payload, it returns back what was the block hash, so that we can actually store it locally. So when we're receiving the next block with apparent… indicating a parent block hash, we already have it in Fortress to see, and yeah, this is… this block is based on food.

Toni Wahrstätter: Right. Yeah, this is great input.

Francesco Risitano: Just on that point, would the execution payload envelope, not contain the block hash?

Potuz: You can, and then… but then again, we will need to validate that the block hash on the payload envelope is the block hash computed on the EL. So, either way, a new payload call should return the block hash, or should validate that the block hash that we provide is the block hash that is claimed in the… in the envelope.

Francesco Risitano: Correct, yep. If I'm not mistaken, I believe the engine API may already be doing that, but I'd need to… I'd need to double check.

Toni Wahrstätter: Yeah, this is great input. It would be also what Etan is, saying, something in the chat. It would be great if… if you could, look… look up the EIP. It's still not merged, but I put a section in there regarding exactly this problem, because I saw the BlockH was used for full versus empty decisions, so it would be great if you could take a look and see if it… what we are currently doing in the EIP makes sense, or if something would have to change to make this work. Awesome. I guess we can take everything else that is unclear async. Thanks a lot.

Parithosh Jayanthi: Okay, Thank you very much. Yeah, just a little some more, maybe feedback about, debugging and tooling aspect. Yeah, do you want to take these topics async, Toni, or do you want to continue?

Toni Wahrstätter: Just going through Dustin's question, see how being able to block hash today. Yeah, I think those are exactly some… Nitty-gritty details that we have to, like, iron out. Like, figure out, like, what would actually change. I guess the first decision we have to take is which of the two delayed statehood EIPs actually gives us the properties that we want in the future for ZKVMs, but of course, as well as builders today. Like, the goal is not only ZKVMs, but also to lower the barriers for new builders to enter, because building will become easier with that EIP. So yeah, there will be a few things to be figured out, exactly, as Dustin mentioned it, around debugging, around tooling.

And yeah, we'll be figured out along the way, I guess.

Parithosh Jayanthi: Thank you. Yeah, please engage on Toni's, EIP, he's linked it in the chat. And we have it in the agenda. Next item on the agenda is, Kev's proposal for HashChain RANDAO. You have the floor, Kev?

Kevaundray Wedderburn: Great. Thanks, Perry. Yeah, so EIP8321, which replaces BLS… the BLS RANDAO contribution from each proposal with the pre-image of a published, hash chain. This, as far as I could tell, was the original proposal, but we chose to go with BLS signatures. And the TLDR is that the process for registering your hash chain is similar to the BLS2 execution change message that we had for withdrawal credentials. Yeah, so that's it. It's not a super complicated EIP, maybe famous last words. Yeah, any questions?

Parithosh Jayanthi: Could you maybe expand on why we need this EIP? Like, what is this.

Kevaundray Wedderburn: Right, yeah, so currently, BLS, is not post-quantum safe, so up… we're basically upgrading, the RANDAO mechanism to be, PQ safe.

T. Wambsgans: I would add that there are probably two ways I can see to do it in a post-quantum way. This is the simplest way. The alternative way would be to derive the RANDAO reveal from the epoch and some kind of private key in a deterministic way, typically via hash, and to prove in ZK That, each time you propose You reveal, you have to… you have to attach a ZK proof to your RANDAO reveal, but it's more complicated. This proposal is, in some sense, much, much simpler.

Parithosh Jayanthi: Yeah, it makes sense. This also seems like the… straightforward proposal to startQifying stuff. Have any client teams had a look at this?

Kevaundray Wedderburn: I think I sent it to Potuz, Sproul, Enrico… I'm not sure if, Dustin, you've taken a look at it, just yet.

Dustin Brody: Yeah, yeah, it's, intriguing, indeed.

Enrico Del Fante: So my first impression on these, and I commented out there, is that we are introducing This mechanism that will, correct me if I'm wrong, and we allocate, like, 32MB in the state. Considering, like, 1 million validators. Yeesh. And then you need to handle… for each validator… each validator needs to handle these new secrets, and you have to pre-build this… this chain. So, there is a little bit of overhead in the state, plus in the… Cryptographic materials management for each validator, then you need to have an additional secret to generate. and everything just for… for… for… for the run… for the RANDAO, and… Yeah, it was, like, a little bit uncomfortable to say that this was just a specific super use… super specific use case to introduce a new… new security.

A new, a new cryptographic, thing that will be only used in this situation, and if we want to introduce similar thing for a similar technique, we need to have a new, field in the state, holding another 32 megabytes of data for each For the whole Validator set to… To have the same feature, but on a different… On a different, protocol, feature. So I was thinking if there is a way to kind of leverage the same technique for multiple things, and introduce this new secret for Validator, and have a possibility to have multiple usage For, for the same… New state and new secret.

Kevaundray Wedderburn: Yeah, so it's definitely correct that, this will… we'll basically need to commit 32 bytes per validator, so it's like adding 32 megabytes to the state. We can reuse at least the secret that's being, created offline, for one-time signatures, which is the current, proposal for going PQ to replace BLS. I'm not super sure if we can… reuse it for anything… any other use cases. I haven't thought about that.

Enrico Del Fante: I mean, if you have the same secret, and then you have two different domains in which you have the chain, so you… the chain will be… I haven't… studied much, the details of what would be, but I believe, anyway, the state… you should have two different… two different parallel chain from… for the same secret, but a different domain, so the secret is the same, but then on the state, you have double the 32MB. So, if we want to have, instead, a chain that is not… is no more a chain, but you have a mix of domains, you… yeah, maybe it becomes a lot of… much more complicated to hand… to make this state to be one, and be reusable in multiple domains.

Kevaundray Wedderburn: Right, yeah, yeah, I agree. I'm… yeah, I'm not super sure about the multiple domain aspect of things, but yeah, the way to reuse the actual secret offline is to hash it with some domain separator, but each one would introduce an extra 32MB, like, per use case that you have. M…

Parithosh Jayanthi: Yeah, maybe Poto's next, and there's, 2 or 3 comments for you, Kev.

Potuz: So… I haven't really looked into… in deep detail, but my first feeling about all of this moving to post quantum is that everything seems to be, like, still in flux. And this particular change, changing RANDAO, seems… Random. Randao… I mean, arguably, the best use of RANDAO is choosing the shuffling. And if anyways, we're gonna keep BLS on the Validator keys, the shuffling is still going to be vulnerable. So it doesn't matter what… what we do with RANDAO, the Validator still can be cracked. So, it seems to me that we're going to fix RANDAO making it post-quantum resistant, but anyways, the only usage of it is not going to be, safe, so… It seems a bit premature.

In particular, one of… one of my favorite things about, like, one of my favorite approaches to going to post-quantum would be to keep BLS, and just have those BLS keys being rotating, so that we can just aggregate. Again, this is a sidetrack, but the thing is that if there is an approach that is approachable to keep BLS and make it post-quantum resistant, then we wouldn't need to modify RANDAO at all. So this seems premature to me.

Kevaundray Wedderburn: Yeah, I can answer those questions. I think the first one is that you can't really make BLS post-quantum secure, right, or resistant. It's just not post-quantum safe. The question about why we should do it now. I think this is the open question as to whether we should do iterative changes to PQ, or if we should try to do it all at once. Yeah, this is a question that It'd be good to get more feedback on it to see how people are thinking about this. Gottfried has… yeah, I guess Gottfried's answered your question about rotating the BLS keys. Francesco also has a good point about if we can wait until the validator set is smaller.

Parithosh Jayanthi: Yeah, I think Francesco had a few questions, I guess. Why do this now when everything else is still vulnerable? Are we sure we'll be using RANDAO in 3 to 4 years? And, even if so, why don't we wait until the Validator set is much smaller?

Kevaundray Wedderburn: Yeah, I think it's a good point on waiting until the Validator set is smaller, I can't remember the number or how long it would take to migrate over to, migrate all of the validators over to using the hash chain RANDAO, but it wasn't a long time.

Parithosh Jayanthi: Okay, and just surfacing other sentiment-based comments, historically, iterative seems to have worked better. But yeah,

Kevaundray Wedderburn: Oh, sorry, Potuz, you disagree with me on what statement? I didn't…

Parithosh Jayanthi: Yeah, Jung, I want to move out of chat and into the call. on Pooja?

Potuz: What is it? I heard my name.

Parithosh Jayanthi: Do you want to move out of chat into the call? Or, like, somewhere.

Potuz: Oh, no, no, no, this is… this is for a long… I mean, this is being discussed already in the post-quantum channel.

Parithosh Jayanthi: Okay, any other comments or questions for Kev?

Kevaundray Wedderburn: Yeah, maybe I'll just bring it up as a… again, that, yeah, the most important question, or one important question here, is whether we want to do this in an iterative manner, or whether we want to try to do it all at once.

T. Wambsgans: As a…

Dustin Brody: Right?

T. Wambsgans: Please, please.

Dustin Brody: Sorry. I, I, I guess, and I certainly, I'm… firmly believe the iterative approach is, I mean, I think along the lines of what, A couple of other people also mentioned, is… I'll just say better, subjectively. But I think the other dimension of this that's being brought up that is, I guess, in principle orthogonal is the question of, and I think Potuz has brought this up as well, but a couple other people have. Is this, how sure are we going to want something, let's say, RANDAO-like? In… going forward, And that's… I think a more… I mean, sort of regardless… right, regardless of the… and that's a separate question than iteratively. You can iteratively introduce, as we've seen many times in Ethereum, something that's sort of obsolete when it's created, and I'm not saying this is that, but…

this iterative.

Kevaundray Wedderburn: Right. Yeah, that makes sense. So, I think more clarity on things like whether we will have RANDAO in the future.

Dustin Brody: Yeah, exactly. I mean, this seems reasonable enough in terms of, given that's a goal. That's the conditionality.

Matthew Keil: I do wonder, to address Potuz' comment of enshrining before final approaches are decided, it might make sense to memorialize the straw map, or whatever the post-quantum vision is from a broader perspective, and that way it can make, How we kind of finalize and narrow down the iterative components, for each iteration.

Parithosh Jayanthi: Yeah, maybe that's a good question for Kev, is… do you want to maybe speak to how the RANDAO change that you're proposing would fit into the bigger picture?

Kevaundray Wedderburn: Yeah, definitely. So, one way to iteratively do it is to do hash chain RANDAO in Hegota. In I-Star, we do the public key registry. In JSTAR, if we have decoupled Consensus, we could do PQ heartbeat, and then k-star or L star, we could do the PQ attestations. I split the heartbeat from attestations, because if you're familiar with decoupled Consensus, these are now separate things. Yeah, the… oh, sorry. Sorry, someone was speaking, you can go.

Matthew Keil: does it make sense from an ACD perspective, or just from a process perspective, to… Because we are very adamant about headliner selections and, doing a lot of that, basically 142 fork ahead, and this feels like a very, an important and, I think, critical change that we probably should look towards in order to ensure timeliness of meeting Q Day. Do we… should we do, as a process perspective, a kind of a… Straw map selection, or a headline planning, or, you know, something we haven't really thought… thought through or done before, but, you know, keeping in, along the lines of what we did with picking Hegota before, you know, two forks ahead, do we want to start thinking more broadly about what PQ, looks like as a broad perspective, as an ecosystem? And then, using that as a…

An approved, quote-unquote, roadmap, that we can all kind of march to.

Kevaundray Wedderburn: Right? Yeah, I mean, for PQ, I do think we need to think a bit more in advance, like, it's not something that we can just do the fork before, so I definitely think some vision of how we're gonna get there, or what the end thing roughly looks like would make sense.

T. Wambsgans: one important question would be which hash function to use in the hash chain. In particular, potentially blank3, as it seems for post-quantum attestations, hash-based XMSS signatures with blank3 are a promising candidates.

Parithosh Jayanthi: Etan has a question about XMSS.

Etan Kissling: Yeah, like, isn't that a stateful scheme? Like, where you have to write to disk, every time you sign?

T. Wambsgans: Yes, it's stateful, but you can use the Ethereum slot as the nonce in your signature scheme. You only need a nonce that you know for sure will never Repeat itself, and this slot is perfect for this.

Etan Kissling: about 3 orcs.

T. Wambsgans: you can store it on… yes, you… I guess you can store it on state that you… Yeah.

Potuz: You can always use as a seed the dependent route and the slot, for example. So… so as long as you… if you're finalizing, you're fine. If you're not finalizing, you just keep track of each fork.

Etan Kissling: Okay.

Kevaundray Wedderburn: Are there any proposals to get rid of, RANDAO? Maybe Francesco…

Francesco D'Amato: I… well, definitely not for me, but I believe there had been in the past. Like, the cryptography team at the EF had worked on such things. I think Gottfried can say more, probably.

Gottfried Herold: I mean, there are options, but they all sort of use, either stuff that we don't have, like, or don't like, such as, time-based encryption schemes. which are questionable security, or threshold encryption-style things, which always have the problem that it really does not give us dynamic, availability, so… for the use case where we use it to shuffle things. So there is not really much of an alternative that we have right now. Unfortunately.

Kevaundray Wedderburn: Okay, makes sense. Yeah, so I think we can probably assume RANDAO will be here in… for a while. But yeah, the question about… Francesco, your previous question about whether we should wait until the validator set is decreased, Not sure… Yeah, definitely something I'd like to discuss more, maybe async would be better.

Parithosh Jayanthi: Yeah, that sounds like a good idea, I would assume discussions happen on the post-quantum chat on ACD, or where would you want people to tune in?

Kevaundray Wedderburn: I don't know if there's a PQ channel in ACD, if there is, then we can… we can do it there.

Parithosh Jayanthi: I think we have some… We can check.

Kevaundray Wedderburn: Probably. Okay, cool. Thank you.

Parithosh Jayanthi: Yes, we have a channel called Post Quantum. Awesome. Anything else on this topic? Great. Next on the agenda is, EIP8015 from, Etan. He wants to remove deposit and ETH1 data fields. Do you have the floor, Etan?

Etan Kissling: Yeah, I mean, it's, Terence's EIP. I only updated it to, like, to be rebased on Glamsterdam. So there is this old deposit mechanism that we used, before Electra. Where we was… where we were monitoring ETH GetHead logs to get the deposit events. That was just later replaced, like, with this request bus. And now the proposal is to just get rid of the remnants of the old mechanism. Like, the ETH1 data, the deposit index… And so on. This is now possible. Because we have the progressive container without messing with the generalized indices.

Parithosh Jayanthi: Nice. Does anyone have questions or comments for Etan? Great. Yeah, in general, it seems like a nice simplification. Yeah, Justin has a question for you, Etan. Would this reduce state growth?

Etan Kissling: It's, I mean, it removes fields from the state. So… but it doesn't… like, it's like a fixed size, right? It has a fixed capacity, so… It's not a lot of… Like, it's like O , it's not something that scales with number of validators or something.

Parithosh Jayanthi: Thank you. Anything else Hegota-related? Otherwise, I do want to mention that the non-headliner submission window closes on the 6th of August, so that's still about 17 days. So please get your submissions in by then. Marius, you wanted to talk about the REST SSV spec, so please feel free now.

Marius van der Wijden: Yes, I posted a link in the chat to last week's ACDE. Unfortunately, I put it on the agenda, and I didn't attend. So, yeah, and it's also mainly for the ACDC crowd anyway. The idea is we are rebuilding the Engine API, based on Reth, currently, and, there are a bunch of methods That we are exposing over the same port. that the CLs are using, that, we don't, we would like to get rid of, because we have to, like, we have to provide their REST SSV equivalent for it. So this… Oh, yeah, just, it's easier to look at it in the, in the, in the issue. The idea is there are a few that,

I guess we will definitely have a replacement for? like, syncing, get blocked by number or hash, and the CHAINID one, the… There are a bunch that we could get rid of if we, decide not to support the… old ETH1 deposit path, anymore, like, block number, call, and get logs. So that goes into the same direction that, that Etan just, just talked about. And, There are some… We have no idea why they are actually in. But those have been used by, like, they were referenced by Lighthouse in some capacity. So yeah, I would like to… Invite all clients to, To comment if there are any other methods that they really rely on over the Engine API path,

that we need to expose. If, there are things that they don't rely on that we can just get rid of. And, yo. That's… that's basically it.

Etan Kissling: I would recommend also reaching out to, like, Helios and the Nimbus Verified Proxy, folks, just to see what they need for the… Like, for the wallets that verify.

Marius van der Wijden: Yeah, no, but this is… this is different, right? This is just on the Engine API. this is… this is not the normal, JSON RPC API that is exposed to the wallets. This is… this is purely for the communication between EL and CL. And, these, like, these methods are duplicated between the normal Engine API and the… And the, the, the, the, the public REST API. So…

Etan Kissling: Oh, I see. So the question is whether we can just drop them from the engine… Exactly. So can we retire the ETH1 deposit path that's essentially the 8015 EIP that I just… Proposed.

Parithosh Jayanthi: Great. Any other questions for Marius?

Marius van der Wijden: Yeah, just to flag that the end state will also look… probably look different than what it is right now, but, like, with ETH syncing, get blocked by number, get blocked by hash, and ETH CHAINID, I think those are the ones that we will probably keep. But they might be, called different. differently, and they might have, different behavior. So, for example, we could… Think about… come. providing some more sophisticated, result for syncing to tell the CL node what the EL is currently doing, which would be, nice for other use cases as well. And so on. So, the question is less which methods, but more what functionality does the CL need? Yeah, happy if you send me some messages about what your client uses, or we can discuss in the SSZ channel on the R&D Discord. Thank you.

Parithosh Jayanthi: Awesome, thank you very much. I think that was the last item on the agenda today. Does anyone else have topics they want to talk about? Yeah, Pooja.

Pooja Ranjan: Thanks, Pari, and yes, this is the same item. I'm trying to bring it again for authors' attention. As it was mentioned earlier in the call, that testing team believes that all EIPs listed on Glamsterdam and Meta EIP are now considered to be SFI. That means it is very close to the mainnet upgrade, the public testnet release. all the proposals are definitely way past the draft status, so I would humbly request authors to kindly take a look at the PRs which are already open, and add your approval. Some of the EIP authors have already provided approvals, but because of the cyclic dependency on other EIPs, they are not being merged as review proposals. So kindly take a look at the list, which is added on,

today's agenda, and add the approval. And one final question for the testing team. Is it okay to consider that whatever is there in CFI are all moving to SFI, and there is no removal from the present SFI list?

Parithosh Jayanthi: Do you mean everything that's in the DevNet? And just cross-checking if there's something… We just have to cross-check if there's anything that's CFI, but not on the DevNet.

Pooja Ranjan: Yes, if that is the case, please do let me know. I have already listed the all CFI EIPs in the comment on the agenda, sharing the link right over here. Please do let me know Oh, I'm sorry. That is, that is another. Delete… I'm trying to share the right link, copy link. Okay, so this is the right link. Cool. So, if there is any change, please do let me know. I am working with Johan to make sure that all SFIs and all EIPs in the MetaIP 7773 are up to date. Thank you, authors, for your support. We really need it. Please, please add approvals.

Parithosh Jayanthi: Thank you. Potuz, did you want to say something at the end?

Potuz: No, sorry, it was technical, I'm asking on interrupt.

Parithosh Jayanthi: Okay, perfect. Yeah, Tama, go ahead.

Thomas Coratger: Yeah, just a question, potuz, like, maybe about, like, your proposition, about PQ, because I am reading, like, the chat conversation. I remember that on the Post Quantum channel, on Telegram, you mentioned some of your ideas about Pbs signature and stuff. our idea is maybe to formalize a bit more, like, a public key registry in a post-quantum way, EIP soonish, let us say. So, do we have, like, a document or a write-up of your ID somewhere, so that we can analyze it a bit more in depth. I have seen a bunch of messages in the post-quantum channel, but not sure I follow exactly.

Potuz: Yeah, so the problem here is that the main idea relies on the existence of an algorithm to create, in a deterministic way, based on a post-quantum safe secret. pairs of BLS keys. On demand, in a way that is deterministic, so that the validator cannot equivocate on this. And the existence of this system is based on a VRF, and of course, this is not my domain, so the… core cryptographers at off-chain Labs are looking into this, and I believe they do have such a system in which the message is small enough that we can actually broadcast it essentially every few e-books. So that will make it a way into having BLS keys for attestations that are still going to be aggregatable by everyone, and make them post-quantum safe, at least for a few minutes.

So, I'll ask them to make that research public, but I believe this is still part of the research.

Thomas Coratger: Okay, okay, thanks, thanks for the update. Please let us know if you have something, or some update, or some document, or anything for us to read. Thanks.

Parithosh Jayanthi: Right, if… is there anything else we want to talk about today? Okay, thank you everyone for coming, and see you next time.

Potuz: Thank you, bye-bye.

Marius van der Wijden: Thank you, bye.

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