PQ Interop #046
Transcript
Ask about this call
Answered from this call's summary and transcript only.
AI-generated — verify against the recording.
Call summary
Targets
- •Zeam: shadow sim analysis with 16–32 node network + Camille's visualization tool — presented next call — 00:26:13
- •Zeam two-level aggregation proposal: tested and results shared by next call — 00:46:59
Decisions
- •Spec to remain stable (no new features); only bug fixes and performance improvements targeting DevNet 5 readiness — 00:41:03
- •Continue long-running multi-client devnets (targeting week+ duration) while testing Zeam and Ethlambda aggregation optimizations in coming weeks — 00:50:37
Highlights
- Devnet Status:
- ·6-client public devnet (32 nodes, 12h run) achieved consistent justification; finality gaps up to 45 min due to divergent recursive aggregation strategies across clients — 00:49:10
- ·12 Ethlambda + 12 Ream 24-validator devnet finalized up to 90,000 slots; ~30-slot finalization lag observed — 00:26:47
- ·Ream ARM compatibility issue and Zeam/Lantern Ziglip P2P interop bug identified; fix applied, devnet restart underway — 00:49:55
- Client Updates:
- ·Lantern: early block-build optimization (build in final interval of previous slot) live in public image; shadow simulator image compatible with Camille's lean shadow fuzzer — 00:27:55
- ·Ethlambda: history pruning reworked (statediff + snapshots every 1,000 blocks); P2P ported to Rust; proposal proof computation disabled to reduce latency — 00:29:01
- ·Gean: fixed configurable attestation committee count rejection bug; spec synced to lean spec head including attestation source and vote filtering changes — 00:30:33
- Fast Finalization:
- ·Anshal proposes implicit vote propagation: validators who voted for block B implicitly voted for ancestor A; modifies process_attestations to credit ancestor targets, reducing finalization gaps — 00:35:41
- ·Memory tradeoff: accumulating implicit votes scales with justifiable slots (bounded ~O(sqrt)) × validator count; block size impact needs evaluation — 00:37:48
- Aggregation Proposals:
- ·Zeam proposes two-level aggregation: Level 1 aggregates raw XMSS only (for safe-target calc); Level 2 aids proposers; removes Type 1 recursive aggregation from proposal pipeline — 00:17:50
- ·Zeam proposal increases slot intervals from 5 to 8 (×0.8s = 6.4s slots); 4 intervals reserved for block building and Type 2 aggregation — 00:21:30
- ·Ethlambda doc: first two optimizations are client-side only; third changes SignedBlock format and requires spec update if adopted; achieved 200ms publish time with 3 attestations — 00:47:16
- Cryptography Binary Fields:
- ·New 'Flock' paper (Starkware + Benedict Bunz/Espresso): binary field proving system, ~600 Blake3 hashes/sec proved, ~2× slowdown vs Poseidon; candidate to replace Poseidon entirely — 00:43:07
- ·Thomas working on XMSS circuit throughput in Binius64 repo; Emil working on LeanVM-b (LeanVM with binary fields + Blake3) — 00:44:58
Action Items
- •Eric (kolby's team) — Investigate and update Hive — currently failing due to old spec version — 00:51:23
- •Ream team — Confirm availability of official Ream ARM-compatible image for multi-client devnet — 00:50:10
Meeting chat40
- grapebaba
Hi, I'm transcribing this call with my Tactiq AI Extension. https://tactiq.io/r/transcribing
- Gajinder Singh
- T. Wambsgans
but by default (when there are no divergent heads), you don't need Type2 right ?
- alan xu
If proof aggregation is already an issue on devnet, will it become an even greater issue on mainnet, where the number of validators is significantly larger?
- Anshal
Replying to "but by default (wh..." no we always need type2 because we fold the block signature as well in block proof, so even without any divergent heads and sync network there are atleast 2 messages
- Gajinder Singh
Replying to "If proof aggregation..." type2 aggregation is just limited to max 8 payloads doesn't matter number of validators
- Anshal
Replying to "If proof aggregati..." we will have more committees so should not get linearly worse atleast. Plus the current aggregator nodes are also not very buffed and ofc we are not considering eventual improvements that we get on aggregation side and client improvements
- Gajinder Singh
Replying to "If proof aggregation..." type1 recursive aggregation in second stage by aggregators will make it feasible to handle a huge number of validators
- Gajinder Singh
Replying to "If proof aggregation..." this is whyy two stage layeer aggregation removes the complexity/compute away from the proposers/normal validators to the specialized aggregators
- T. Wambsgans
Replying to "but by default (when..." Not sure to understand. You mean you also aggregate the XMSS coming from block producer to sign its block, with the rest of the signatures (from attesters) ?
- Kamil Salakhiev
do you have a repo with ethp2p rust?
- Kamil Salakhiev
@Pablo Deymo | Lambda
- Mega | Lambda
Replying to "@Pablo Deymo | Lambd..." It’s private for now
- Kamil Salakhiev
Reacted to "It’s private for now" with 👍
- Pablo Deymo | Lambda
Replying to "@Pablo Deymo | Lambd..." I will make it public ASAP
- Gajinder Singh
Reacted to "I will make it publi..." with 👏🏾
- Gajinder Singh
Replying to "@Pablo Deymo | Lambd..." @Parthasarathy Ramanujam for zig implementation
- Parthasarathy Ramanujam
Replying to "@Pablo Deymo | Lambd..." We have one ready with the spec that was 2 weeks ago.https://github.com/blockblaz/zig-ethp2p
- Kamil Salakhiev
Replying to "@Pablo Deymo | Lambd..." I am just doing some rust simulations, where EC broadcast would be useful. Also curious how you plan to have both ethp2p and libp2p. E.g. will they plan on a single port
- Gajinder Singh
Replying to "@Pablo Deymo | Lambd..." can we then validate it on shadow sims and may be interop with ethlambda on it
- Parthasarathy Ramanujam
Replying to "@Pablo Deymo | Lambd..." Yes, I’ll ensure its spec complete.
- Kamil Salakhiev
Replying to "@Pablo Deymo | Lambd..." just FYI, ethp2p is WIP. So stuff will 100% change
- Pablo Deymo | Lambda
Replying to "@Pablo Deymo | Lambd..." We should include Raul to talk about that
- alan xu
Replying to "If proof aggregation..." Sorry, where can I find the definition of type1 and type2 aggregation?
- Kamil Salakhiev
Replying to "@Pablo Deymo | Lambd..." overall we definetely will need EC broadcast for leanvm proofs propagation. These are numbers for EC broadcast vs gossipsub for 128KB payload [Full message cannot be displayed on this version]
- Mega | Lambda
Reacted to "overall we definetel..." with 🔥
- T. Wambsgans
on my side I am working on leanVM-b (leanVM with binary field + blake3) https://github.com/leanEthereum/leanVM-b
- Gajinder Singh
Reacted to "overall we definetel..." with 🔥
- Mihir Faujdar
Reacted to "on my side I am working on leanVM-b (leanVM with binary field + blake3) https://github.com/leanEthereum/leanVM-b" with 👍
- Gajinder Singh
Replying to "@Pablo Deymo | Lambd..." what is the size of the payloads in this
- Mega | Lambda
Reacted to "on my side I am work..." with 🔥
- Anshal
Reacted to "on my side I am wo..." with 🔥
- Mihir Faujdar
Reacted to "on my side I am working on leanVM-b (leanVM with binary field + blake3) https://github.com/leanEthereum/leanVM-b" with 🔥
- Gajinder Singh
Reacted to "on my side I am work..." with 🔥
- T. Wambsgans
I recommand (for those interested in binary field snark) binius64 doc: https://www.binius.xyz/blueprint/ (Warnig: it's hardcore)
- Gajinder Singh
we will be able to test our psoposal by next call
- Kamil Salakhiev
Replying to "@Pablo Deymo | Lambd..." 128KB
- Gajinder Singh
tradeoff is the bandwidth
- Gajinder Singh
Replying to "tradeoff is the band..." today beacom block size excluding the execution payload is just 2KB so its a huge tradeoff
- Kamil Salakhiev
Reacted to "I recommand (for tho..." with 🔥
Key decisions
Spec to remain stable (no new features); only bug fixes and performance improvements targeting DevNet 5 readiness
PFItargeting DevNet 5 readinessContinue long-running multi-client devnets (targeting week+ duration) while testing Zeam and Ethlambda aggregation optimizations in coming weeks
multi-client devnets