Will Corcoran:Alright, good morning, all.
Transcript
Will Corcoran:Welcome to… this is PQ interrupt call number 30.
Will Corcoran:Let's jump in with some client updates.
Will Corcoran:Loom team.
Gajinder Singh:Hello, everyone. Hi, Bill.
Gajinder Singh:Yeah, so we have been working on stabilizing our client. We have… we identified a few issues with the way we were importing things in fork choice and processing.
Gajinder Singh:New and known payloads, so that is something that we fixed.
Gajinder Singh:And, we have also identif… we also identified a small issue in the spec, for finalization, in straight transition function, where basically, whenever new finalized slot was, discovered, it was…
Gajinder Singh:It was not then iteratively used, in the next, for deciding for the next finalizations in the same block.
Gajinder Singh:So the issue was that if you basically split up the votes among two blocks, it would…
Gajinder Singh:It would result in a different…
Gajinder Singh:Finalization, and and basically we wanted a behavior in which,
Gajinder Singh:things would be more stable and consistent across blocks. So, we did a… we did an upstream PR for it, and if other clients have
Gajinder Singh:Seen it, please do implement it.
Gajinder Singh:Because otherwise it will result into consensus issues.
Gajinder Singh:Apart from that, we worked on, DevNet 3,
Gajinder Singh:runs, and, whatever issues Katya and Path had discovered, basically, they,
Gajinder Singh:They notified it to the teams.
Gajinder Singh:And, we have also improved… we have also improved Lean Quick Start.
Gajinder Singh:incorporated changes in the inquisitive for DevNet 3.
Gajinder Singh:On spec work, we have worked on DevNet 4, the PR is… Unsurance PR is out, and, so please give a review, I'm also reviewing it, as well as we put a DevNet 5 PR, which, we propose that we basically merge into DevNet 4 itself, so that, so the DevNet 5 PR was…
Gajinder Singh:For separating out,
Gajinder Singh:the proposer and the tester key, which we will… we are proposing that we just do it as DevNet.
Gajinder Singh:Portage settles.
Gajinder Singh:Because otherwise, DevNet forwards changes are not so many.
Gajinder Singh:Yep, so we have been doing debuggings and figuring out stability issues and working a bit on spec work as well, so yeah.
Will Corcoran:Excellent.
Will Corcoran:I'm gonna share my screen.
Will Corcoran:Feel free to call anything out here. I've been screwing around with Claude Code myself, old dog, learning new tricks, trying to write some cron jobs to, like, highlight all the work that you all are doing, so this runs a weekly summary and just pulls in, like, all the PRs that have been merged, opened, most discussed.
Will Corcoran:So I can leave this open, and I'd like to… maybe…
Will Corcoran:Refine this as we go, but feel free to
Will Corcoran:highlight any PRs that you want to talk about, and I can drop them into the chat.
Will Corcoran:Loom team.
Shariq Naiyer:Sweet, sweet. Yeah, that looks pretty… that looks pretty good. On the REAM side, we… we have been aggressively debugging, what's happening in our DevNets.
Shariq Naiyer:And, some of the issues we found, around consensus, as, as Gajinder pointed out, we initially matched the spec, but then, as Gajinder pointed out, that we would like to go for, the behavior that we had previously, we reverted that change. We were testing out check… we were having some issues with checkpoint sync, and, we found that the issue
Shariq Naiyer:who was, initialize… we weren't initializing the Folk Choice store, or…
Shariq Naiyer:if… we weren't initializing the FolkChoice store properly with some… with some configs that needed to be changed. So… so that has been… that has been updated, and as we can see in today's DevNet, I'm finding the clients to be fairly stable.
Shariq Naiyer:we're at, like, a thousand slots right now, 1,000 finalized slots, and, I'm expect… and if all clients have merged the, the… the spec change, like, 443, then, then I think… I think we'll have a pretty good DevNet today. As for…
Shariq Naiyer:Apart from that, we added DevNet3 metrics, and we added additional testing. We added a CI that now runs for 3 hours, but it tests our client
Shariq Naiyer:in relation to all other clients, I think… I think it's pretty beneficial to have that for now. Eventually we'll move that to, like, a nightly CI. As for… as for DevNet 4, we're reviewing the DevNet 4, spec PR.
Shariq Naiyer:But… but yeah, beyond that, I don't think we've had much happen in DevNet 4 this week.
Shariq Naiyer:As for the spec side of things, we've pushed a PR for,
Shariq Naiyer:we pushed a couple of PRs, O push to PR for changing the signature to, signature serialization to fixed bytes, from the, from the lean spec client, and I think in the lean spec as well, because all other clients were implementing fixed bytes, which was different from the spec, and we pushed to PR to,
Shariq Naiyer:for the API spec test to test the folk choice endpoint as well.
Shariq Naiyer:And… and yeah, yeah, that's all from our end.
Will Corcoran:Sure.
Will Corcoran:Grandine team.
Will Corcoran:I think your audio cut out, Russell.
Ruslan Tushov:Hello.
Will Corcoran:Perfect.
Ruslan Tushov:Can you hear me now?
Will Corcoran:Yep.
Ruslan Tushov:Okay, so, today… Someone…
Ruslan Tushov:wrote in the chat about, fork choice P endpoint. We added, pull requests. Currently, it's under review.
Ruslan Tushov:Also, we merged some remaining DevNet30 requests that were not merged into master.
Ruslan Tushov:Also cut, helped us to find some crash, in our computerMD ghost head function.
Ruslan Tushov:We'll check it later, and somehow, when we restart the docker, port becomes busy.
Ruslan Tushov:It's, uses network host, from Linkwick Start.
Ruslan Tushov:And we use Bustache for networking.
Ruslan Tushov:didn't… Also, didn't find a solution yet.
Ruslan Tushov:Oh… Also, we are doing some…
Ruslan Tushov:We're looking up into automating some interop tests, simple interop tests, which, for example, check that chain growth and finalizes and checks other metrics.
Ruslan Tushov:Also, not restarts and syncing.
Ruslan Tushov:But we're still cleaning it up, so not published yet.
Ruslan Tushov:Thank you, that's all.
Will Corcoran:Great, thanks, Austin. And the…
Will Corcoran:Chat Russellin was referring to is in the tooling channel of the main telegram group.
Will Corcoran:If you're interested.
Will Corcoran:mihir is… was not able to make it,
Will Corcoran:I will post a message that he wrote, and I… Chat to… So…
Will Corcoran:If you're interested in reviewing that, that PR… There you go.
Will Corcoran:Grandine.
Shaaibu Suleiman |gean:Yes, hello.
Shaaibu Suleiman |gean:Yeah, so for, what we've been able to do, we've implemented, persistent storage.
Shaaibu Suleiman |gean:We've chose to move forward with, BoltDB, and we've, implemented, that for persistent storage.
Shaaibu Suleiman |gean:And we have also actively started on, working on DevNet3, basically.
Shaaibu Suleiman |gean:We've, separated, both, signature aggregation from block production, basically, by introducing the aggregator rule, and of course, added, or introduced two more topics.
Shaaibu Suleiman |gean:For, propagation of both signed attestation and signed aggregated attestation, which are the requirements.
Shaaibu Suleiman |gean:For DEFNET3, alongside, you know, other requirements that we are actively working on.
Shaaibu Suleiman |gean:Right now. We have, a draft PR that is currently actively under review.
Shaaibu Suleiman |gean:For DevNet 3, to see how we can facilitate, things and complete, DevNet 3.
Shaaibu Suleiman |gean:But, all things being equal, by the end of this week, we should, raise a PR on Lean Quick Start to participate, in…
Shaaibu Suleiman |gean:the multi-client, interop, and all that. So basically, that's that, that's that from us, Ajin. Thank you.
Will Corcoran:Amazing, thank you.
Will Corcoran:EthLambda.
Pablo Deymo | Lambda:Hello!
Pablo Deymo | Lambda:We were working on the memory issues we had. We implemented a circular offer.
Pablo Deymo | Lambda:to put a limit to the memory consumption.
Pablo Deymo | Lambda:We also merged the beer with the pruning.
Pablo Deymo | Lambda:We… We've implemented a new version of our… a framework.
Pablo Deymo | Lambda:a concurrency for the actor model. We call it Spawn. It's a library of Lambda class, and so we moved to this new version, which is more ergonomic, written in Rust.
Pablo Deymo | Lambda:We also put this, the usage of this framework in P2P module of EthLambda.
Pablo Deymo | Lambda:We made some networking improvements to improve the resilience of the node. For example, excluding, failed peers, from block fetch.
Pablo Deymo | Lambda:from roughly retry.
Pablo Deymo | Lambda:And we made some small changes we were doing in the spec to align to the Boolean spec, changing the naming of epoch to slow, and signing the station message to data.
Pablo Deymo | Lambda:And, the last but not least, we implemented the pending lead metrics we have.
Pablo Deymo | Lambda:Especially the Aggregator, we had, Depending there.
Pablo Deymo | Lambda:So… That's it.
Pablo Deymo | Lambda:Thank you.
Will Corcoran:Thank you.
Will Corcoran:Any other client updates?
Will Corcoran:All right. Moving on to specs, research.
Thomas Coratger:Hmm, yeah,
Thomas Coratger:This week, we haven't worked that much, on spec in order to let client teams,
Thomas Coratger:debug and adapt with DevNet 3.
Thomas Coratger:The good news on the spec is that, thanks to recent PR,
Thomas Coratger:it seems that we have interrupt between the lean spec in Python and other clients, at least Zim, for the other ones, I am not sure, so that is pretty good.
Thomas Coratger:We also added, with the PR of PARTA, yesterday, the metrics.
Thomas Coratger:in LeanSpec, in order to be able to integrate with Prometheus and LeanQuick Start stuff.
Thomas Coratger:Like, your other clients.
Thomas Coratger:On the research side, we worked a lot with, blonQ3 and LinVM,
Thomas Coratger:Emily can detail further the LinVM work, but basically, we worked this week to improve a lot the performance of Poseidon 1.
Thomas Coratger:both in plain text and in the proving context. That is,
Thomas Coratger:we have… we are… we have two targets of optimization. One is just hashing inputs using Poseidon 1, and the other one is proving hashes of Poseidon 1.
Thomas Coratger:So, we worked on both of these targets with various fields combinations, so baby bear, koala bear.
Thomas Coratger:Goldilocks and Merced 31, so we worked to improve the benchmark.
Thomas Coratger:to see how fast we can get, when compared to Poseidon 1, Poseidon 2, in order to have real comparison, and it appears that approximately, for the plain text comparison.
Thomas Coratger:We are only 1.8 slower than Poseidon 2, which is a pretty good news, because we thought it would be much worse.
Thomas Coratger:So yeah, this is pretty good news, and we worked a lot on this. If you are interested by all of this work, you can check all of the PR that we made on Prong History recently.
Thomas Coratger:Yesterday, also, we released, Plonkies 3. 0.5, so that is a new release, with all of this changed inside.
Thomas Coratger:So, yeah, that is basically all on the research side. Emil, feel free to add anything about LeanVM that you want to add.
T. Wambsgans:I will… thank you. I will just add about DevNet4 that
T. Wambsgans:There is now a peer in LINSIG to include the new ZK-friendly encodings, and should be made very soon. I think Benedict
T. Wambsgans:Mainly,
T. Wambsgans:like, wrote some minor comments, but it should be good. And then, once this is merged, maybe today or in some days, like tomorrow, you know, we'll try to do the corresponding DevNet4 branch on Lin Multisig to have a recursive aggregation.
T. Wambsgans:with the official LINSIG repo.
T. Wambsgans:for DevNet 4. So, don't know if it's going to be ready in the next week, but,
T. Wambsgans:There is some progress, at least.
Will Corcoran:Awesome, thank you guys. Any other spec research-related updates?
Will Corcoran:Or discussion topics, anyone would like to table.
Thomas Coratger:Just if you are interested, I think that, next week, this is the 20, I think.
Thomas Coratger:We have heatproof call number 8.
Thomas Coratger:focused on… on Poseidon.
Thomas Coratger:So, Justin organized this, but if you are interested, you can, you can just check it, and we'll have a bunch of discussions and presentations about all of the recent updates about Poseidon.
Gajinder Singh:So I have one discussion topic to bring up, which is basically, what is the P2P topography that we need
Gajinder Singh:Because now we will, soon be experimenting with greater than one subnet.
Gajinder Singh:And then… Basically, this question will come up, that what is our best topography.
Gajinder Singh:For connections for the mesh.
Gajinder Singh:That is good for us. Other thing that we also need to figure out is
Gajinder Singh:All the validators in the…
Gajinder Singh:In the… in particular subnet, they should be…
Gajinder Singh:they should be ignoring the gossip attestration messages that come to them, or they should just be not subscribing and flood publishing. So, what is the best
Gajinder Singh:P2P, strategy for… Spreading out, the signed attestration messages, so that… The aggregator can…
Gajinder Singh:basically get most of them in a very short amount of hops. So this is something…
Gajinder Singh:I think we need to think even for…
Gajinder Singh:DevNet3, and apart from that, we also need to…
Gajinder Singh:See that whether the spec is,
Gajinder Singh:Compatible to having greater than one
Gajinder Singh:subnet, as well as basically, you know, how we configure it in Lean Quick Start.
Gajinder Singh:and how we distribute the validators among the nodes. So this is something I think,
Gajinder Singh:will be some… that some… will be a concern that I'll be looking into this week, but it is also…
Gajinder Singh:Good that other people can weigh in what they think about this.
Will Corcoran:Hi, Camille.
Kamil Salakhiev:Yeah, just my thoughts on that.
Kamil Salakhiev:Yeah, it's, I'm a bit…
Kamil Salakhiev:I would say, like, it's… it's not that simple. I mean, yeah, we have, like, grid, oh, sorry, not the grid, like, we use Gossip Self today.
Kamil Salakhiev:For stations propagation, yeah, some alternatives could be, like, grid or, you know, other kind of structured topology. I'm a bit,
Kamil Salakhiev:Yeah, I'm not kind of ready to say that, yeah, grid is kind of the best choice right now, because the… well, it's good for propagations, I mean, we did all the research, and yeah, for example, in Beam Simulator, but it has…
Kamil Salakhiev:Some privacy concerns, like we need to expose validators.
Kamil Salakhiev:basically, to be able to match validators' signing keys with their P2P keys and P2P addresses, which we want to avoid, because, yeah, we have certain privacy assumptions in existing Ethereum networks today, which we would like to keep.
Kamil Salakhiev:So it's not as simple. I would say that also.
Kamil Salakhiev:Maybe the best… well, maybe,
Kamil Salakhiev:The… the… my… maybe the thing that…
Kamil Salakhiev:Yeah, from my perspective, I would rather focus not on attestation propagation optimization today, but rather on,
Kamil Salakhiev:things like… First… Well, blocks propagation and proofs propagation, because, like, we have
Kamil Salakhiev:Once we have… because that's a lot of data, like, each block, when we have a proof.
Kamil Salakhiev:it's at the very least 128 kilobytes. Each proof is 128 kilobytes, and if you have multiple aggregators, so each aggregator creates 128 kilobytes message.
Kamil Salakhiev:Which could be a lot in a large network.
Kamil Salakhiev:There are… there are some ongoing work
Kamil Salakhiev:in ETP2P with, Azure-coded broadcast, yeah, I think…
Kamil Salakhiev:Yeah, you can check Raul's recent tweets about that. The result looks good, so I would maybe…
Kamil Salakhiev:From my perspective, at least, I would first try to…
Kamil Salakhiev:somehow introduce this thing, I mean, first blocks propagation, maybe first, and then…
Kamil Salakhiev:Move propagation, or do this at the same time, using some recording strategies.
Kamil Salakhiev:That would be a good playground to kind of check the research that, yeah, the
Kamil Salakhiev:Networking team did, so just check it in practice.
Thomas Coratger:Do you think this is relevant to… and do you think we can do that soon, to integrate all of the effort of Raul and his team inside the LeanSpec and Lean DevNet, as I say? Everything related to broadcast, ESP2P, all of this?
Kamil Salakhiev:Wow, the soon… define soon. Yeah,
Kamil Salakhiev:Yeah, it would take some time, maybe… I don't know.
Kamil Salakhiev:I need to maybe hands-on on that a bit, to investigate a bit deeper how the propagation strategies were implemented in the benchmarks.
Kamil Salakhiev:That's Sukun from, yeah, networking team did.
Kamil Salakhiev:So, and then, yeah, we might think to introduce this… yeah, I'm trying to think, maybe, yeah, you can help me, guys, like, what should… where should we start, like, if we want to go with recorded broadcast, like, maybe start with proof propagation or blocks propagation improvements,
Kamil Salakhiev:So, I just want… I just want to add, you know, while we are…
Gajinder Singh:about blocks propagation, propagation. Currently, the topology is a star topology, everyone is connected to everyone. So, I mean, even before we start talking about and start researching about blocks propagation or proof propagation, we need to, for example.
Gajinder Singh:target some topology that… that we think is something that is good. And we can do that without introducing the discovery, because in Dean Quick Start, we know what all nodes are, and we can basically supply… we can create the topology by supplying them
Gajinder Singh:The, those particular boot nodes, so we can, on the script level itself.
Gajinder Singh:create the topology. So, question is, what is the topology that we are going for? And then we can basically talk about block propagation optimizations, and…
Gajinder Singh:proof propagation optimizations, because right now at STAR, there is… everything is within single hop, so there is no…
Kamil Salakhiev:No.
Kamil Salakhiev:Yeah, just a correction, I…
Kamil Salakhiev:I don't think it's a start apology. Yes, you might have, like, maybe your clients, they connect to all the peers, they maintain connections to all the peers from the node's YAML.
Kamil Salakhiev:However, Gossip Sub has… Mesh size…
Kamil Salakhiev:I don't remember, 8, I believe.
Kamil Salakhiev:So, even though we maintain connections, even if your peer… even if your client connect… connects to all of the peers, which, by the way, in Clean, we did it in a way that
Kamil Salakhiev:at least we had a configuration so that we can connect only to a subset of peers, like, maybe 20 peers. Otherwise.
Kamil Salakhiev:shadow would just crash with too many connections and messages. So basically, even if your client connects to all the peers in the notes YAML, in your mesh, you only maintain… well, basically, you propagate messages only to 8 peers.
Kamil Salakhiev:Which is your merch site, so it's not really a start apology, it's more like a gossip.
Kamil Salakhiev:Even today, so we don't have one hope. We have multiple hopes.
Gajinder Singh:Yeah, I mean, to go over that, we basically first need to increase our nodes. I mean, we are not there. So, one thing is to basically push our nodes number high, and then…
Gajinder Singh:Again, come back to what you're saying.
Kamil Salakhiev:Sorry, do what?
Kamil Salakhiev:With the notes.
Gajinder Singh:We need to push the nodes that are… that we spin up in our network, and then only we can measure
Gajinder Singh:What is the propagation time for block and proofs and…
Gajinder Singh:Do optimizations on top of that, on the lines that you are saying.
Kamil Salakhiev:Yeah, we did that with,
Kamil Salakhiev:clean, basically. We ran analysis under shadow, to check, like, the blocks propagation, blocks propagation, and the sessions propagation, and…
Kamil Salakhiev:Yeah, we need to rerun it, maybe, when… yeah, the issue was that when we had… because we were testing, I believe, with DevNet… I need to double-check… DevNet 2 or DevNet 3. Basically, the issue was that a single block could have multiple
Kamil Salakhiev:Proofs included in it, so the block size…
Kamil Salakhiev:have, like, could be, like, maybe, I don't know, up to 1MB, which is really a lot.
Kamil Salakhiev:So…
Kamil Salakhiev:if we're still doing that, maybe that's one thing that we should optimize, like, make sure that our block can only have single, snark in it, otherwise, yeah, it's…
Gajinder Singh:It is not possible to have a single snack in the block for the reason that, I mean, you will pack
Gajinder Singh:For example, signatures, which have different registration data, right? So…
Kamil Salakhiev:I don't think it is possible to have a single proof in the block, but…
Gajinder Singh:What we can do is maybe target… for,
Gajinder Singh:For the aggregator, right? So… so that that particular thing can get delivered in a single packet.
Kamil Salakhiev:You mean aggregate? Well, how is it?
Kamil Salakhiev:Well, so you're saying that, yeah, we're not worried that our block size could
Kamil Salakhiev:Could be, like, I don't know, megabyte.
Gajinder Singh:I'm saying that.
Kamil Salakhiev:Because for me, this is a bit of a concern.
Gajinder Singh:never come below to the point where you have a single data packet, right? You can put it in a single data packet and optimize it. It will definitely get broken into multiple packets, because there will be multiple proofs, at least we might support, like.
Gajinder Singh:four different… Attestation, data, in… in our attestations, right? So we might support… support that. But…
Gajinder Singh:Again, and then we'll have a different proof for the block signature.
Gajinder Singh:itself, right? So… so we… we might not be able to…
Gajinder Singh:limit the block size to a point where basically we can transmit in a single packet, unless the proof size is, like, very small. But it is possible that with the aggregators, we might be able to do that, because they only need to transmit
Gajinder Singh:a single proof, and along with that, estration data. So there… there we definitely have the space for optimization, where we can compress the proof.
Gajinder Singh:To a size where it gets transmitted in a single bucket.
Kamil Salakhiev:Hmm… Okay, a question, like, do we have,
Kamil Salakhiev:like, upper limit for a number of proofs that could be included in a single block. Basically, the question is, do we have an upper limit for a block size today?
Kamil Salakhiev:Or it could be… Infant, due to the number of Proofs, could be unlimited.
Gajinder Singh:So, yeah, I mean…
Gajinder Singh:We will have… we will have… we will definitely need to have, for example, a size
Gajinder Singh:Of four different attestation data that can be packed, and different registration data directly maps to different proofs.
Gajinder Singh:in the signatures, in that signatures, right? So, because we are not aggregating across
Gajinder Singh:different messages. So… so that is… that… that directly maps over there, unless we come to a point where we are aggregating across different messages, but…
Gajinder Singh:Then we can also independently verify the signature across… Signature.
Gajinder Singh:against these particular, you know, independent messages, so…
Gajinder Singh:Maybe we can also think about that, if that can be done, if,
Gajinder Singh:Because we… because Emil did provide us an API to…
Gajinder Singh:Aggregate, against two different messages, and…
Gajinder Singh:We have not really thought… thought it through in the sense that
Gajinder Singh:We came up with a different solution for the proposer signature and attestration signature, but
Gajinder Singh:aggregating across different messages for attestations, right? So that is something that…
Gajinder Singh:One can think and see that, if that can work, then basically
Gajinder Singh:It is possible to have just one
Gajinder Singh:Proof signature in the… in the block.
Anshal:Virginia, even without that, for a particular attestation data, if I am a validator and I'm not an aggregator, and I receive multiple aggregates which… which basically cover a different set of validators, so for a single attestation data as well, I'll have to include, like, multiple, proofs.
Gajinder Singh:So basically, we are in… in…
Gajinder Singh:In a configuration where the proposal will always aggregate.
Anshal:If we get into that configuration, then yeah, we won't need it. Then… and along with that, if we have, like,
Anshal:multiple message aggregation, then we'll be able to basically aggregate over multiple attestations and produce a single proof, but in the current configuration.
Anshal:We'll have multiple proofs, even for a single attestation data, even after recursive aggregation.
Kamil Salakhiev:Is it even possible, from LinVM perspective to kind of…
Kamil Salakhiev:I don't know, have multiple aggregations for… I mean, different aggregations created on top of different messages, and then kind of merge them into a single.
T. Wambsgans:Yes.
T. Wambsgans:symbol, I believe. I believe… Everything is possible, you see there.
T. Wambsgans:If you can phrase it, we can prove it, yes.
Gajinder Singh:I mean, it's not difficult. Basically, the verification
Gajinder Singh:against the independent messages. If that is possible, then this approach can be taken.
Kamil Salakhiev:Hmm, cool. Yeah, maybe that's something that we can introduce in some upcoming DevNet.
Kamil Salakhiev:I mean, aggregating from multiple Well, multiple messages-based aggregations.
T. Wambsgans:Yeah.
Gajinder Singh:Yes, sir.
Kamil Salakhiev:Yeah, Yamil, please go ahead.
T. Wambsgans:No, I mean, I believe it's very…
T. Wambsgans:easy compared to everything else to add… if it's… if I understand correctly, we only need the possibility to have different messages, is that correct?
Gajinder Singh:So when we say that we need possibility to aggregate different messages, what it really means is that if I have the proof.
Gajinder Singh:And I used, for example, poor messages to aggregate. So if I have the proof, I can directly validate against
Gajinder Singh:Message 1 without requiring message 2, message 3, message 4, because…
Gajinder Singh:Yes. Then I can say that over.
Gajinder Singh:If we can do that, then definitely we can use this, because then it is like just having an independent signature for this particular message, and…
Gajinder Singh:Oh, yeah.
T. Wambsgans:I believe we can do… we can do that, yes.
T. Wambsgans:Basically, what is… we can have an, I think, an kind of an arbitrary number of messages, with… and potentially,
T. Wambsgans:In the beginning, there is only one message, and then you can add the other messages on top of this, and yes.
Gajinder Singh:So, if we can basically use the same…
Gajinder Singh:Signature to validate different messages, then definitely it's possible that,
T. Wambsgans:Sorry, sorry, you mean, sorry, you mean…
T. Wambsgans:Different… sorry, one signature, for different messages, That's okay, I didn't understand.
Gajinder Singh:we aggregate… so we aggregate proofs across different messages to get one final aggregated proof, right? So, this proof is now…
Gajinder Singh:we can independently validate against message 1 without needing message 2, message 3, message 4, let's say, and then can independently validate against message 2. So if we can do that, then basically it's like.
Gajinder Singh:This is the final proof that you can just reuse for message 1 and similarly, message 2.
Gajinder Singh:And so it acts like a normal, proof.
T. Wambsgans:Okay, so you want to, you want to weigh…
T. Wambsgans:So basically, you want a single SNARC proof that contains allegations across multiple messages, but you want to be able to verify it for message 1 if you don't know message 2, is that correct?
Gajinder Singh:Yes, I mean, somehow it can still be done, because I can… I can create a specialized proof for
Gajinder Singh:message 1 by saying that, okay, message 2, message C, message 4 hash was this, and I can just put it… push it in the specialized message, one proof, right? So I can… so I can create… if I can create such a specialized message one proof very easily from the aggregated message, then…
Gajinder Singh:I can basically see it as an independent…
Gajinder Singh:Message 1 signature, that can just…
Gajinder Singh:That can be validated to say that, okay, you know, these validators voted for this particular message one.
Gajinder Singh:And then I can basically use it, use it as…
Gajinder Singh:As I can then… the other block proposals can basically aggregate it further, right? So, there can be recursive aggregation on top of it.
Gajinder Singh:And can be packed into a block. I just need to make sure that
Gajinder Singh:I can independently verify them, which I think… It is possible if… I just…
Gajinder Singh:even, you know, back the message 2, message 3, message 4 hash, along with the proof itself, so that I can say that, okay, this message once proof is…
Gajinder Singh:This aggregated proof plus Concatination of the hashes of the other messages.
T. Wambsgans:I'm not sure to follow entirely, but maybe we can continue this chat
T. Wambsgans:After the call, but intuitively, if you can write it… yeah, if you can express it.
T. Wambsgans:We should be able to make it work, in some sense.
Gajinder Singh:Yeah, I think we'll be able to make it work.
Gajinder Singh:Yeah, we'll continue after.
Anshal:But, do we even need to independently verify it with each of the messages? Because in the block, we'll have all the, all the attestation messages and a single proof, so we should be able to, we'll have, like, all the four messages, and we'll just need to…
Anshal:Verify that the aggregate is basically
Anshal:An aggregate of all the… these four messages itself.
Anshal:So, along with attestation data, we'll be storing, like, the participation bits to which each attestation was signed, and
Anshal:Basically, with that, we can reconstruct the whole thing.
Gajinder Singh:I mean, it's always better if you can recursively pack the proof with other proofs that might come up, right? So…
Gajinder Singh:But yes, let's…
Anshal:sort of inspect and see whether we actually need it? Yeah, yeah, I mean, like, we'll be recursively constructing a single proof, but we'll still have, like, the attestation data for…
Anshal:all these different messages. So, suppose we have 4 different attestation data. So, for each attestation data, I believe we'll be storing the participation bits who have… basically the validators who have signed to that particular attestation data. And that… all of that will be packed in a block, along with the single proof.
Anshal:So… Right, that's fine.
Gajinder Singh:when I am just talking about one particular registration data, let's say that it's message 1, I want to forget about message 2, message 3, and message 4, right? So…
Gajinder Singh:I don't want to carry them together, or if I can basically carry them again, together with the…
Gajinder Singh:proof itself, that basically makes it possible for me to say that, okay, you know, I have an independent proof
Gajinder Singh:To validate for message 1.
Anshal:Hmm.
Anshal:Got it. Okay.
Gajinder Singh:Basically, it makes the thought process easier of how we can process and aggregate, further aggregate these messages. But I think it should be possible.
Anshal:Yeah.
Kamil Salakhiev:Huh.
T. Wambsgans:Yeah.
Kamil Salakhiev:Oh, sorry, yeah.
T. Wambsgans:Josephine…
T. Wambsgans:Not entirely sure to understand, but from what I understand, yeah, I also agree that it should be possible, yes.
T. Wambsgans:Please come in.
Kamil Salakhiev:Yeah, my… just another concern is that,
Kamil Salakhiev:Yeah, it still would be great to have some kind of limit, maybe, of number of proofs that we might… that we need to aggregate in such a way, because
Kamil Salakhiev:I believe we still have a target aggregation rate for proofs is, like, maybe 10 SNARCs per second, maybe Emil can correct me, and maybe there are improvements for that estimate already. But yeah, if we're talking… it's kind of a significant time.
Kamil Salakhiev:from the… Yeah, consensus, critical path perspective, that, yeah, we need to optimize.
Gajinder Singh:So, I think it will automatically be limited by the fact that when, you know,
Gajinder Singh:When… when the network sees new block, and most of the network confirms it, basically, it will result into a new
Gajinder Singh:attestation data as a head vote, right? So…
Gajinder Singh:In that sense, obviously, I think automatically it will come to a point where, you know, you won't keep on regulatively aggregating the same
Gajinder Singh:Same proof, right? So…
Kamil Salakhiev:Hmm…
Kamil Salakhiev:So it's not, like, only block proposals' responsibility to aggregate all these proofs for different messages, but it will be done recursively? Is that what you're saying?
Gajinder Singh:No, proposer… so, a test… anyone can do it, right? Aggregators generally will aggregate only fresh proofs, so it's a proposal responsibility to recursively aggregate
Gajinder Singh:I mean, aggregators can also do it, nothing is stopping the aggregators to not…
Gajinder Singh:Recursively aggregate and, make a better…
Gajinder Singh:And produce a better aggregate, right? So, if that particular registration data is still in play, But…
Gajinder Singh:the way I see it, most of the aggregators will consume new proofs, and the proposer will recursively aggregate them in a consensus where, you know, we see that the head is flowing, and the finalization is flowing, and all that, right? So, whenever there is new attestation data, new
Gajinder Singh:New proofs are gonna come, which means that there is a new head that the network recognizes.
Gajinder Singh:So if most of the network sees some… sees a block, definitely…
Gajinder Singh:New proofs will automatically come into the picture.
Kamil Salakhiev:Yeah, it would be great to have it written down somewhere, yeah, I need to… Think of, like…
Kamil Salakhiev:Yeah, maybe there are some attacks possible. Anyway, anyway.
Kamil Salakhiev:Yeah, I mean, if you think this might work, that would be great if we could use this approach to just have a single
Kamil Salakhiev:Eventually, maybe a single just… just a single proof in a block.
Kamil Salakhiev:That's the first way we can optimize. I mean, this is kind of low-hang fruit. We can basically do that to reduce block size.
Kamil Salakhiev:And then, in parallel, yeah, we might start working, I mean, yeah, maybe I should draft some… maybe have some kind of…
Kamil Salakhiev:write up about how we can introduce Reasure Code broadcast, just kind of investigate what's been going on,
Kamil Salakhiev:from the P2P team, research, and yeah, how… what's the best way to put it into…
Kamil Salakhiev:Into the leans perk in some way.
Kamil Salakhiev:Yeah, let me think about this. Yeah, I'll try to share something.
Will Corcoran:Excellent.
Will Corcoran:Any other spec or research-related discussion items?
Will Corcoran:Metrics and observability. Anything that you would like to… Able for this week.
Katya:Yeah, hello everyone. So, currently I'm running DevNet3 on all the 9, servers, so,
Katya:Currently, we lost Zim, but it's because of the old image. I don't have an updated image yet. As soon as I have it, I will replace Loom with a new one.
Katya:And I had to stop Grandin. I think no one on the call from Grandin's team, but they have memory leaks, so I will notify them in the chat. For all the teams, currently, what I need, is
Katya:API and metrics flags updates, so please, in the tooling, response to my message, what, what flags, clients have, because we are refactoring Lean Quick Start, so we need this, link point and for metrics. That's it, thank you.
Will Corcoran:Excellent. Any other… Discussion topics.
Will Corcoran:Great. Well, that felt like a really productive call, as usual.
Will Corcoran:I will see you again in a week.
Shariq Naiyer:Have it going, guys.
Katya:Right?
Anshal:Hi, everyone.
Pablo Deymo | Lambda:I wrote.
Chat Logs
00:16:37
Will Corcoran:https://github.com/leanEthereum/leanSpec/pull/443
00:16:42
Will Corcoran:Spec changes to review
00:17:13
Will Corcoran:https://github.com/leanEthereum/pm/pull/71
00:17:20
Will Corcoran:Devent-4 plan
00:20:00
Will Corcoran:I wanted to inform you that I won’t be able to attend the today’s PQ Interop meeting. However, I have provided an update in this GitHub issue on the progress made for Lantern: https://github.com/ethereum/pm/issues/1962#issuecomment-4038902590
00:33:47
Will Corcoran:Sounds like a great FORT MODE discussion item 🙂
00:47:46
Will Corcoran:“If you can express it, we can prove it”
-T.Wambsgans
00:49:23
Kamil Salakhiev:Replying to "“If you can express ..."
I want t shirt with this quote
Summary
13 highlights
· 4 action itemsExperimental
Summary
13 highlights · 4 action itemsExperimentaldevnet 3 status
devnet 4 progress
devnet 5 design
networking and scale
Decisions
Action Items
- Emil, Benedict: Merge ZK-friendly encoding PR in leanSig to unblock DevNet-400:26:44
- Gajinder, Emil, client teams: Explore multi-message aggregation API to reduce block size to single proof00:42:47
- Gajinder, networking teams: Define P2P topology for subnet scaling and validator distribution00:36:59
- All client teams: Update API and metrics flags for leanQuickStart refactor00:54:24
Targets
- March 20, 2026 - ethproofs call #8 focused on Poseidon optimizations00:27:52