Jun Song

@junsong

Joined on Jan 18, 2025

  • tl;dr Project proposal is now merged! The proposal is now live on EPF repo. Navigated a couple of options to implement SSZ-QL on Prysm. (Write-up) It's always possible to implement something theoretically, but I believe aligning with the current codebase (and near future plans) is also important. Details Merging our project proposal In this week, we spent some hours to resolve Radek's comment: The structure of this response differs significantly from the previous one. We should aim to unify them for better UX. Is it possible to treat a non-multiproof response as a special case of multiproof?
     Like  Bookmark
  • [!Note] This write-up contains some important things to know and presents rough ideas when implementing SSZ-QL. You can see the full project proposal here. Introduction I've been exploring ways to implement SSZ-QL in Prysm codebase, and found that there are two options available right now. Before getting into the options, I think it will be better to understand how BeaconState is fetched and handled in the context of Beacon API. Personally, I feel much better on the second option (Byte-Parsing Engine) but always welcome for any feedbacks. Background: Fetching BeaconState In Prysm, beacon endpoints with state_id usually fetch the corresponding BeaconState using Stater interface. (beacon-chain/rpc/lookup/stater.go) // Stater is responsible for retrieving states.
     Like  Bookmark
  • [!Note] Implementing this endpoint is a part of EPF6 project by Jun and Nando. You could check our project proposal to get more context (motivation, progress, etc.). [!CAUTION] This document is currently under construction. Introduction Handles multiple queries on BeaconState with proof of inclusion. Specification
     Like  Bookmark
  • Motivation What problem is your project is solving? Why is it important and what area of the protocol will be affected? Currently, consensus clients have limited ability to provide specific data fields in BeaconState along with their corresponding proofs. While Ethereum Light Client has introduced several paths to be proven, it lacks of standardization in how they generate and retrieve these proofs. Retrieving an entire BeaconState using the /eth/v2/debug/beacon/states/{state_id} is not practical. On mainnet, the size of the BeaconState Slot 12145344 is roughly 271MB-large enough to burden the serving node and the client, and to be latency sensitive over typical network links. Moreover, the specification itself classifies the debug namespace as “a set of endpoints intended for chain diagnostics and not for public exposure.” (Some argues BeaconState is a "God object") A more scalable approach is to supply Merkle proofs or multiproofs. These techniques, already standard across blockchain workflows, allow data producers to transmit only the minimal cryptographic path needed to authenticate a specific field, while consumers avoid downloading the entire state. The inefficiency becomes evident when a verifier needs just one field that is not validators or balances:
     Like 1 Bookmark
  • tl;dr Refined the proposal to make it concise, finally opened a PR. Several discussions about technical stuffs with Nando. Started coding! Details I dedicated most of my time to 1) refine the proposal (PR is open now.) and 2) discuss with Nando about the scope of our project and document management. Finalized the Proposal image
     Like  Bookmark
  • tl;dr Got some feedbacks and reviews from mentors. Resolved some concerns from mentors. Details image Link to the message In this week, I mostly focused on refining the details of the project proposal. Nando and I requested to review our project proposals to the mentors, and received valuable feedbacks from them.
     Like  Bookmark
  • tl;dr Now I'm leaving Cannes! In this week, I DID Presented (Timeline: 00:22:16 - 00:31:00) my initial proposal at EPF day. (Slide) Worked with Nando to finish our initial project proposal. One-liner for our project:We propose a new Beacon API endpoint that introduces an SSZ Query Language (SSZ-QL), including the ability to generate merkle proofs for the queried data. Details EPF Day It was so glad to meet other fellows in person, and we talked a lot so we get to know each other better. All fellows have different backgrounds, so I could learn their insights and thoughts!
     Like  Bookmark
  • tl;dr This week was a really solid week: I DID Submitted a draft PR for GMP (Generalization of Merkle Proofs) in Prysm Finalized my project scope: SSZ-QL + GMP Chatted with amazing core devs in CL with full of insights Met Nando (also a fellow of this cohort) for collaboration Details For this week I mostly spent my time preparing the proposal for the EPF day at Cannes. I delved into the details of the projects, and wrote some lines of code to demonstrate how this could be implemented. I also had some amazing conversations with core devs including Radek and Manu from Prysm and Etan from Nimbus! Here's my slide. Let me break down the things that I've done in the last week, in chronoical order. You can just look up the slide as it is the result of my this week as well.
     Like  Bookmark
  • image Yesterday, I sent my initial draft via Prysm's Discord server, and Bastin suggested to take a glimpse of SSZ Query Language project as well. As it is tightly coupled to my initial interest (Merkle Proofs of Everything), I took a look of it. This post includes some notes and questions to the team. Notes { "anchor": "<stateRoot>", "querySpec": { "validators": { "range": [
     Like  Bookmark
  • Introduce new function: ProofByFieldIndex You can see a draft PR in this link. As I mentioned at the last dev update, there are some redundant code that can be simplified (e.g. CurrentSyncCommitteeProof, NextSyncCommitteeProof and FinalizedRootProof). ProofByFieldIndex is introduced to 1) make logic common and 2) generalize the proof generation in the level of the fields in BeaconState. // ProofByFieldIndex constructs proofs for given field index with lock acquisition. func (b *BeaconState) ProofByFieldIndex(ctx context.Context, f types.FieldIndex) ([][]byte, error) { b.lock.Lock() defer b.lock.Unlock()
     Like  Bookmark
  • Summary Explored the existing Prysm's codebase. Reviewed other options for Prysm (e.g. Migrate e2e using Assertoor) Details As I shared in Week 0 updates, I'm interested in generalizing merkle proofs for Prysm. Since Prysm uses Bazel as a main build tool, I've reviewed my experience of using Bazel and ran some tests (e.g. e2e) in my local environment. Prysm has hard-coded logics for each field in the beacon state(See proofs.go). Some of the functions and constants can be generalized: finalizedRootIndex (and also CurrentSyncCommitteeGeneralizedIndex, NextSyncCommitteeGeneralizedIndex): currently precomputed as 105, but if we want to generalize the proof generation, this can be replaced.
     Like  Bookmark
  • Hi, I'm Jun from South Korea, and really thrilled to participate for this upcoming cohort. I just finished (submitted my tiny compiler today!) the Spring semester in my university, and this semester was super cool: building a compiler/OS from scratch, exploring great ideas from cryptographers (I like Diffie-Hellman most.), and learning some basic concepts of PL (Type checker, Continuation, etc.). I will also attend EthCC@Cannes, so feel free to chat with me about anything! After a glimpse, I decided to focus on SSZ-related features in Prysm. (SSZ Query Language & Merkle Proofs of Everything) for few months. There are two primary reasons for this: Recently I studied Merkle Multiproof for passing necessary fields into zkVM guest, so I expect to keep this momentum up. My favorite language is Go (and also Rust), and I had several experiences contributing to Prysm codebase. What's next Explore Prysm's codebase Delve into SSZ and its merklization
     Like  Bookmark