ZKProof 5.5 in Barcelona was a blast! We focused on standardization, and all the 100 participants, well, participated! 
Mary Maller’s overview of the modular approach to specifying Plonk
In this talk (slides are here), Mary clearly explained the components of the forming standard and rationale. She successfully called for community involvement through working groups and iterative development. By leading the discussion, she recruited participants to advance the standards effort, aligned on goals like interoperability and simplicity, and built momentum to drive this complex long-term project forward.
Overview:
- Mary gave an overview of the goal to write specifications for Plonk in a modular way, covering the constraint system, optimizer, interactive oracle proof (IOP), polynomial commitments, and Fiat-Shamir transform.
- She emphasized the need for simplicity, interoperability, and concrete applications to drive adoption.
- The process will involve multiple working groups for each component, requiring close collaboration over many years.
Constraint System:
- Discussed the Plonk constraint system and the need for simplicity, comprehensiveness, and wide compatibility.
- Presented the Plonk optimizations like shifts and rotations and the need to preserve meaning.
- Showed examples of draft specs they are working on for Plonk constraints.
Interactive Oracle Proof:
- Explained how IOPs work at an abstract level with polynomials.
- The IOP working group needs to focus on interoperability with other components.
Oracle Compiler:
- This compiles the IOP into an actual interactive protocol using polynomial commitments.
- The choice of polynomial commitment scheme defines properties like proof size, crypto assumptions, etc.
- The oracle compiler enables switching out polynomial commitments easily.
- APIs and security requirements need to be defined.
Polynomial Commitments:
- Working groups needed for specific schemes like Bulletproofs, FRI, and KZG.
- Consistent APIs needed across schemes.
- Important to get 128 bits of security even with grinding attacks.
- Need to standardize things like pairings.
Fiat-Shamir Compiler:
- Can leverage prior work from sigma protocol specifications.
Discussion:
- Participants split into groups to discuss forming working groups, timelines, goals, and interdependencies.
- Emphasized need for concrete applications and constraints to drive adoption.
- Discussed how standards could allow switching to quantum-safe schemes.
- Talked through open questions and challenges around modularity.
Key Takeaways:
- Modular specifications enabling interoperability are critical.
- Community involvement through working groups will be essential to succeed.
- Managing timelines and dependencies between groups will be challenging but important.
- Keeping specifications simple, even if less optimized will promote adoption.
- Concrete applications like threshold crypto will help drive use.
- This will be an iterative, multi-year process requiring continuous feedback.