Post-Quantum Interop Call #46

Transcript

Thomas Coratger: Hello, hello everyone. So yeah, let's get started. So today we will just make like the classical round of updates. Then we can talk again about DevNet 5 and blocking stuff. And then we'll give, like, very short updates on… What we are doing on the cryptographic front with binary fields techniques, especially. So yeah, let's get started with the client updates Zeam first.

Gajinder Singh: Thanks, Toma. So, we have been working on fixing issues that we uncovered during interrupt runs, as well as shadow runs, and we have now reached a point where we can say that Zeam is robust and stable to participate. With other clients on, multi-devnet. A multi-subnet network, and we have already been running Oh. few of these interrupt runs, and with 4 clients and 8 subnets we were able to. So we were able to demonstrate a long duration network with with justification happening frequently and finalization happening intermittently. And the reason for that is obviously some of The aggregators, they're providing attestation state and

There is a delay in… block proposal. So these are basically 2 of the major reasons why why things happen with delay. And, so we have… a proposal for which would solve both of these issues. One of the issues is that other clients while they are publishing the aggregates, they are trying to not only do recursion on, not only do aggregation on ROG XMS gossip messages, but also include the aggregates produced by other aggregators, which is Although a better aggregate, but they are doing with a delay, which is not good for the network, so… So other clients should basically prioritize first publishing, the first level of aggregate, and then improving it and working on it further. So we have

So in our proposal that we have shared. I think on the GitHub issue, and I can share it over here. So we basically propose that we introduce two level of aggregation where there is first level of aggregation in which only raw XMS messages are aggregated and they are basically consumed. by the validators to calculate their safe targeted sector, while at the same time, at the same interval. There is a second round of aggregation that is primarily happening to to basically aid aid the proposers so that they don't actually have to do a type one recursive aggregation. and then basically removing the type, one recursive aggregation totally from the proposal pipeline which basically leaves

proposer to only deal with type 2 aggregation. And even for that, basically, we We are proposing to add 3 intervals through the block proposal itself of 0 point 8 s. So now we have total 8 intervals and 0 2. 4 intervals will be for block proposer and to build a block and to publish it, and then followed by other things which you can find in this particular proposal. Apart from that, we Also, are working on 2 optimizations PRs for… to optimizations. We are basically which is a smart deconstruction and fast finalization. But we are basically working a bit on it. Again, those are mentioned in this particular proposal. Oh.

Thomas Coratger: You mean like, you mean eight interval instead of five right now, right?

Gajinder Singh: Yes, correct.

Thomas Coratger: And so it gives like 6.4 seconds, right?

Gajinder Singh: Correct.

Thomas Coratger: False logs. Yes. And so, I guess that you have tested this idea, or not? Yes, I guess so.

Gajinder Singh: No, we have not tested this idea, but I don't… so we can test this idea in this coming week. Oh. If more or less people are aligned on this particular front. But I don't basically see any challenge in it because about 90 percentile of the book proposals like happen in 2.4, 2.6 seconds. And basically, given this time for type 2 aggregation, I think this 4 intervals of 0.8 is sufficient. For a block to… No. For… for block building and proposal. So, I am…

Thomas Coratger: I'm not sure, like, to understand, because in your table, like, in the after colon, you mentioned that After you only have type, you only have type two. for the proposal aggregation while before we had type one plus type two. But I was thinking that in the previous call, you mentioned that for you, Type 2 is a big slowdown.

Gajinder Singh: Yes.

Thomas Coratger: It's in your test.

Gajinder Singh: So. Correct. So type type 2 only is a big store slowdown, which is why we are proposing to increase the interval time type one recursive aggregation. We are now, for example, proposing to happen at the same interval in which safe target calculation is happening, so that Proposer does not have to do a recursive aggregation, and we are also removing the constraint that attestation data has to be unique. So basically, if we remove the constraint, then the aim of doing recursive aggregation was to do less and less of signatures. Right? And with the with type 2 aggregation, we already have just one single block signature. So, there is no need for us to do a Type 1 aggregation, enforcing the Type 1 aggregation on the proposal. What we basically need is for very good

aggregated type, one signatures. And for that we basically need to do a 2 round of aggregation. First round is just upon the raw, so that other clients also they don't try to mix in other signatures with the raw signatures, and they basically publish their signatures on time. That is very important, and that is a thing that we have learned from running our interrupt runs. is that, other clients are basically trying to make a better aggregate, but they are sending it quite late, and this is why everything's, so this is why Finality happen in intermittent bouts, and and and the aim of type. One aggregation is to just produce better aggregates, and if we have better aggregates already, that means that most of the times

the aggregations that… the attestation data that will be packed in the block are going to be unique, because they are packed in a greedy manner. And in that sense, type 2 aggregation is sufficient to cover everything. Our assumption that type 2 aggregation over time will become more and more efficient to basically make sure that it can be performed under 0 point 4 s. Which is, I think, what the target for type 2 aggregation should be. But till that happens, or till or to avoid using a stronger hardware for Devnets and for testing runs, we basically increase the time For block building itself, just for the right to aggregation.

Thomas Coratger: Okay, thank you. Thanks for the, the recap.

Gajinder Singh: I don'.

Thomas Coratger: Awesome.

Gajinder Singh: Yeah, on one last front on the shuttle Sims. Yeah, we have. also got some stability over there after various fixes we we did. Now, what we are trying to do is basically run a 32 node or a 16 node network, and then we will use Camille's visualization tool. So basically to analyze the shadow Sims and present it. present our analysis in the next call. Yeah, that's beyond.

Thomas Coratger: Okay, great. Ring?

Unnawut Leepaisalsuwanna: I, I don't see Sharik on the list, so maybe I can give a quick update. So… We are mostly focusing on just testing the PQ interop with all the clients, so we managed to do a 24-validator, DevNet, it's 12 Eve Lambda and 12 Ream. We were able to finalize up to 90,000 slots. But again, with the attestation time, I think we are expecting to experience something like 30 slots behind for finalization or something like that. But they are finalizing. And our next step for that is mostly just for a PQN trial for now. So we will be adding. other clients, we'll be testing with other clients, going forward. And then apart from that, we are, yeah, so as usual, making improvements to Hive, and so on.

Thomas Coratger: Okay, great. Qlean.

Ruslan Tushov: Hello. We didn't have much time, working on clean. Still catching up on high tests. Not all tests are green yet for clean. Currently, that's all. Thank you.

Thomas Coratger: Okay, thanks. Lantern?

Mihir Faujdar: Yep, thanks, Thomas. Hi, everyone. So Yeah, basically, since last week, we added an optimization similar to Eth lambda, where basically build a block earlier in the into like, basically build a block in the final interval of the previous slot. So that optimization is enabled in the. current public image and as well as added support for the simplified block building. Pr, that was submitted to lean spec. and as well as have released a new image for shadow simulator. the image. This image is compatible with the lean shadow fuzzer tool that is built by Camille. So thanks, Camille, for merging that and yeah, I will be working with same team to just fix the interrupt issues that were surfaced recently. Thank you.

Thomas Coratger: Great, thank you. Ethlambda?

Pablo Deymo: We changed our history pruning to give all the Chinese state with minimal disk usage. We now store stdiff with snapshots every 1,000 blocks and discard block signatures only instead of the whole block for finalized blocks. As a research side quest, we ported its P2P to Rust. And integrated this to Ethlambda for gossip. We implemented the privatization, That was just mentioned the bill one interval early. And disabled proposal proof combustion. to reduce proposal load and to ensure more consistent blog publish latency. And also yesterday we shared a document explaining our stance regarding bumping the celebration. And… And we are currently looking into the results that Partha shared yesterday.

running internal devnets and debugging issues. And we are working on changing the aggregator logic to ensure we prioritize raw signature aggregation for the current slots. So that's for our week. Thank you.

Thomas Coratger: Great. Thanks for sharing the document as well. Gean?

Bankat | gean: Thanks, Tomas. Hi, everyone. So, on Gean's side, we shipped two things recently. The first was a fix. So that Gean accepts a configurable attestation committee count, because previously it was rejecting anything other than its default. So any higher attestation, attestation committee count was blocked on Gean, so thanks to Partha who flagged that, we've fixed that. And on the spec side, we've caught up with the current head of LeanSpec, including the attestation source from HN. And still vote filtering changes. For now, all spec changes are green. And then on shadow. The NS has matured from last week's report into something we are now running real experiments on. We are currently driving towards single client, multi-client, and multi-subnet topologies.

We added a prover cost model that charges our XMSS aggregates and verify work as configurable signatures per second reads. So that will let us reproduce slow proving regimes deterministically. So looking ahead, we'll keep tracking spec changes closely while improving performance on gene and also making progress on shadow. So that's the update on gene. Thank you.

Thomas Coratger: Great. Amazing. Grandine?

Mercy Boma Naps-Nkari: Hello! Good afternoon. So We did some clean up peers, and we're currently working on supporting shadow, and that should be ready by end of today. And then, on the proposal, I have a question, because there's a place that I'm not sure if I'm reading it correctly, based on the first finalization, which is, the… split target scenario. So Is it, like, how does, It triggers a shared, source recognition. That's the part I don't get.

Thomas Coratger: Sorry, I think I missed the last… 10 seconds of your… of your talk. Can you just repeat, maybe?

Mercy Boma Naps-Nkari: Yeah, so I'm talking about the hack empty that was just shared. So the fast finalization. Right up, so… There is no rule of how the source target should be.

Gajinder Singh: So, in SDF, there is no rule of what source and what target is. Basically, you just… apply the STF rules, right? And… and fork choice is basically there to help you select what source and target is. And, what, what Anshul's PR is suggesting is that So currently, if you are, you have some target. And, other validators are voting onto some target, which is ancestor of your target. You should be able to propagate your vote to your… Ancestral target, so that you can then have a justification over that. So I think this is what the fast finalization is about. Angel, if you wanna clarify for that.

Mercy Boma Naps-Nkari: Sorry, I think maybe I did not put my question correctly. I mean, it doesn't, like, say what triggers the shared source recognition, so, like, how… it fits into, like, an existing justification logic. That's what I'm trying to understand.

Gajinder Singh: So, it is…

Mercy Boma Naps-Nkari: Like, if it stays safe under Byzantine votes, like… Won't a consensus change without an algorithm? Can it be implemented consistently, like across all clients? That's where I'm coming from.

Gajinder Singh: Yeah, so it is not really a big change, it is just a change in SDF. Where you will basically propagate your vote. up the ancestral chain as well. To… Help the foster justification. Some, target which could be the ancestor of The votes of some. of some validators, right? So, it should not, in theory, really be a big change. Across… The client code base is just an SDF base changed.

Anshal Shukla: Yeah, so it just changes the process attestations function, so right now, what I have proposed is that, suppose there's a chain with source target 1, like, a block A and a block B, so there can be a bunch of attestations which target A, which have, like, targeted A, and a bunch of attestations that have target as B, so we individually see that the target should have two-thirds of the vote to move the finalization and justification ahead, but suppose, if, the source A and B all lie on the same chain, so, validators who have voted for B have implicitly voted for A as well. we don't incorporate that, and due to that, we saw yesterday that, on the… on the data that Partha shared, that we were seeing, long delays and finalizations and justifications. So, if… if we,

if we consider these implicit words, we'll be able to move A ahead, even though we didn't explicitly receive these attestations there. The only downside of this is that on the long… when there are long hauls in finalization and attestations, when we try to do the… When we try to basically, get votes on all these, different blocks. then we'll have, like, a huge, huge data structure that will lay around in the memory that we'll have to accumulate our votes over. Because we'll… and it will be, like, fun… it will be proportional to, like, the number of… Justifiable slots, which is plus 5, and then we have targets as, Tag it as pronic in a square root number, so, shouldn't be very huge, but it will, it will grow, and it will be some…

Function of that into, like, the number of validators that we have.

Gajinder Singh: Yeah, since justifiable slots become Exponentially sparse as we go. further down, so I think, yes, it would not lead to too many candidates, where you will have to propagate the WhatsApp. But yes, we… we basically need to… check whether… This basically is computationally not heavy as well as does not generate bigger blocks because finally justification justifications needs to be serialized in the block as a big factor. So there is that factor as well.

Mercy Boma Naps-Nkari: Okay, thank you. That's what I was trying to figure out, the bigger block issue. The… sorry, one last thing. On the new block, size cap, it's… The proofs per data are allowed. What bounds, like, is there, like, a new bound to mass attestation data? Like,

Gajinder Singh: I didn't really get the question.

Mercy Boma Naps-Nkari: I mean, on the new, block size cap, if multiple proofs per data are allowed, what sort of bounds, the block? in terms of mass attestation data.

Gajinder Singh: So, I think…

Mercy Boma Naps-Nkari: Dick.

Gajinder Singh: They're.

Mercy Boma Naps-Nkari: Current one no longer holds.

Gajinder Singh: There is still only one signature in the hand, so… There is no blow-up in the size, and there are still 8 max attestations. Extra attestations that you can pack, so basically that gives you… only 8 Max slots, even when you are trying to fill it. With the same attestation data.

Mercy Boma Naps-Nkari: The reason I'm asking is that in grinding, we had to, like, reduce Max's decision data to four instead of eight in order to accommodate the timing and everything. So I was trying to see if this.

Gajinder Singh: That is fine. It's going to be a little problem. So, any cla… so… so you will not have the problem now, because you don't need to do type 1 recursion, right? So… only Type 2, Type 2 proof is what will take time and it will stay constant for. For your rate slots or if you have less than 8 slots then it will. Be less than that but yes it is sort of bounded in that manner. And as a client you can optimize for your own client. whatever strategy you want to pack right? You want to just go with 4. Just go with 4 you want to go with 8 to go with it, or whatever time based strategy you want to do for packing the test stations, knowing that

Packing more attestations make your block more canonical, so that that is this particular, you know, self-interest. for the block proposal to pack as as much as destinations as possible. And And basically REST, it is up to clients to figure out whatever strategies they want to apply in. an ideal world, I think, where we have Type 2 aggregation, Happening in 0.4 second. Basically, the problem totally goes away. So REST depends upon your client entirely.

Thomas Coratger: When you mean that, you mean that… this should not be specified into the spec. This is, like, just an implementation choice from the client.

Gajinder Singh: Yeah, I think if… for example, Grandine wants to just pack 4 attestations out of 8 attestation slots, then it is It doesn't need to be in spec. It's basically a client optimization as such. But the total overall bound for type 2 verification type 2 proof generation is anyway bounded.

Thomas Coratger: It, yeah. I can give a brief update on what we are doing. And then we can go back to the question of DevNet 5. I have seen, like, so you guys proposing, like, basically the… the two ACMD staff, one from East London, and one from the Zeam team. Like, probably they make sense, and we should test them. I have seen, for example, in Ethlambda, I think the Ethlambda proposal has been tested, because there are numbers and graphics. So… yeah, they run a node with nice performance and stuff, so probably this should be tested if this can help. On the… on the spec front, I haven't touched anything. Because, as I mentioned last time, and with many of you individually, like.

The goal there is to stabilize a bit on the spec. Of course, we should fix bug and we should target like performance improvements when possible, including like block building and all of this stuff, but not adding new feature, because what we want there is to stabilize a bit on PQ. So, yeah, this is as planned, but on the other side, we have done, like, quite a lot of work on the binary fields, so, as you may have known. Last week was published a new paper that is called Flock. By the authors of, so mainly, like, a collaboration between Starkware and some University staff and Benedict Bunz from Espresso. Flock basically is a binary field new proving system.

That is kind of taking existing stuff from Binius and existing term check technique plus on top of that implements a bunch of new optimizations on different stuff. Not going into the details, but… it implements some optimization at the sum-check level, at the IOP level, also on the fact that now you are proving batch stuff. Which can help also with performance, so we have very nice numbers. On the paper. So basically, it can prove around 600 Blake3 hash functions per second. So this is very big. This is approximately only a 2x slowdown when compared to Poseidon. So this is great because we want to test this in order to know if we can get rid of post-hidden completely via this new technique.

This includes a lot of additional complexity because binary field proving systems by nature are much more complex than the existing one with PLONK and the prime fields that we all know. So this is a lot more complexity, so right now we are working basically on two fronts. So… I am personally working on the Binius64 repo with Jim from, irreducible, X irreducible. On checking how many XMSs we can prove per second as a circuit, because there is already a XMSS circuit inside BNU's 64 repo. And Emil, on his side, is working on how to adapt LeanVM. Using binary feeds, so maybe, Emil, you want to say a few words about this?

T. Wambsgans: Hi, no, it's really just working on binary LeanVM. That's it. Thanks.

Thomas Coratger: So yeah, this is the work that we are doing right now, full time. We will keep you updated if we have, like, novelties or stuff like this. And. I will check a bit more in the… in the future week as well, but maybe to redesign a bit this PQ interrupt call to add a bit more of cryptography, maybe. And maybe we can… since we can debug all of the… all of the client stuff async, maybe we can get rid of the client updates and just do important presentation involving, for example, today this could have been, like. One small go through the two proposals, plus some present… some short presentation about, like, binary fields or anything like this.

So, Yeah, maybe we can… we will do like this. I will check, I need to think a bit more. But this is the work that we have done. Then my proposal, since… an important point of this call is DevNet 5, is that in the future days, we can test both of the optimization. Since the Ethlambda optimization is already tested, maybe it's worth implementing it. I don't know, maybe you want to comment, Ethlambda folks, on this attendee that you shared. Do you think it should go into the specification, or do you think this is a, like, A client optimization? What is your opinion?

Mega | Lambda: Yeah, we, in the doc we share, we share three optimizations, the first two.

Thomas Coratger: Yeah.

Mega | Lambda: We don't think they're needed in the spec. They are more like client… implement a client side optimizations. The 3rd one is a is a concept. It changes the the format of the block type. So of the sign block type, so it would need to be on the spec. If we adopt it.

Thomas Coratger: Yeah, and you didn't increase the slot time, right? I am not sure, I am reading on the fly, but…

Mega | Lambda: You know, we managed to reach, like, I think.

Thomas Coratger: Okay.

Mega | Lambda: and publish time of 200 milliseconds into the slot with three attestations in a block.

Thomas Coratger: Okay, great. And yeah, we already mentioned, like, the ZIM proposal as well. So, yeah, maybe we can check these two type of optimizations. And. So yeah, this is up to you guys, since a lot of them are, like, client-side optimizations. To just test it and stuff like this. like… Gajinder, I think that you mentioned that you tested, like, a DevNet running, like, Running right now, do you know how many validators do you have right now? And what do you expect in, let's say, the coming weeks?

Gajinder Singh: Yeah, I think Partha will be able to provide with the latest stats. Partha?

Parthasarathy Ramanujam: Yeah, so the public DevNet, we tested with 32 nodes. We ran 12-hour DevNet with 4 clients yesterday, and, there were no issues with, justification of finalization. The only issue observed was, occasionally, or, We did not have finality for up to 45 minutes, and then suddenly it jumped. Which is probably expected, because different clients had different methods in which they were performing the aggregates. Recursive aggregation actually delays achieving the two-third vote, so When, occasionally, when the chain grows, it starts, the finality starts to take time. I restarted the DevNet today with all six clients, but we've run into some issues because, Ream's image that I was using was… did not support, ARM, machines. When I used their official image, the Ream subnet alone could not keep up with the…

chain, and was continuously catching up. So, and, I also identified an interop issue between Zeam's latest Ziglip P2P and, Lantern, which I fixed right now, so I'm going to do another, restart shortly. And if, I mean, if or anybody else from the VM team can confirm the availability of, or the official REAM image, we can include that also. Hopefully, I think we are pretty stable now, at least justification is happening, even though it's a bit delayed. So we are ready for long-running DevNets. If required, we can probably start doing it for a week or maybe longer and see how things go.

Thomas Coratger: Okay, great. So let us test these optimizations in the coming weeks, and let us continue to debug the devnets and increase the number of validators as long as we debug. If there is nothing else from you guys, this is okay for me, and we can… Just, like, do the work async, and share updates. Great. Thanks a lot, guys. See you next week. Yeah, yeah.

Mega | Lambda: I just wanted to add that Hive is failing, I think, since the last time I saw it. I believe it's using an old version of the spec, and that's what causes it to fail. I'm not sure who's who has access to it, but It would be nice to… to check that. Me too.

Kolby Moroz Liebl: Eric can look into it today.

Mega | Lambda: Thank you.

Thomas Coratger: Great. Thanks a lot, guys. See you next week, bye-bye.

Parthasarathy Ramanujam: Thank you.

Mihir Faujdar: Thanks, everyone. Bye.

Gajinder Singh: Oh, good one.

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