!(https://i.imgur.com/WeIvTiX.png =150x) **Home Edition**
# Discussion notes #5: Plumo: Towards Scalable, Interoperable Blockchains Using Ultra Light Validation Systems
Presenter: Psi Vesely and Michael Straka
- Ariel Gabizon
- Kobi Gurkan
- Philipp Jovanovic
- Asa Oines
- Marek Olszewski
- Michael Straka
- Eran Tromer
- Psi Vesely
To be presented on 2020-05-04.
* [Latest PDF version](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-plumo_celolightclient.pdf)
* [Miro Whiteboard](https://zkproof.org/workshop3-board)
* [SoK Working Group](https://community.zkproof.org/g/WG_PLUMO)
* [Additional related links](https://hackmd.io/@HtwXZr-PTFCniCs7fWFSmQ/B1AwbdI_8)
## Real-time notes
_Note taker: Abida Haque_
> Others are welcome to augment/annotate using notes. Add your name. ---MyName
- Problem: Blockchains are big
- How can we make verification easier?
### BLS Verification
Can have a problem of EC computations inside arith ckt, want the ckt defined over scalar field of curve. Actually want 2-chain.
second curve, and original curve need to be pairing friendly. Constrains choices.
BW6 should be better than SW6, looking at it currently.
### Hybrid Hash Function
First compress using Blake, then apply Pedersen hashing.
Could use the newer R1CS "algebraic flavored" hash functions. Hybrid hash functions are more conservative.
Other hash-to-curve options?
### Incremental Proofs
Scaling from POV of prover. Still have a question of proving a whole bunch of authenticated data as chain grows, etc.
General solution is incremental proofs.
Can be done with recursive proof composition. Makes it possible to prove a lot of data. Ultralight verifier only needs to verify final proof.
Instead, use inductive solution. Prove adjacent chunks of the chain at a time. Because of the SPV-like assumption, don't strictly have verifier succinctness. But allows you to check a large time length.
### SNARK Circuit
Chain of epoch messages. Per epoch message, check aggregate public key was formed with>=2/3 current committee public key. Check message number is 1+last.
One time: check aggregate multisignature is valid.
### Performance results
For both proving, verifying.
Takes only a few seconds for bootstrapping on mobile devices.
- (Karim Baghery): do you need zk in this scenario?
- (Psi Vesely): not having it leads to significant speedup in the prover side
- (Karim Baghery): is it allowed to have verifier generate parameters? In this case we do need public verification, and we want a single proof.
- (Madhi Sedaghat) How this construction is comparable with the existing schemes like FlyClient and so on, and naïve solutions?
- (Michael Straka) not sure how efficiency compares with FlyClient. In our case equivalent about 10 days (threshold at which verifying snark proof is more efficient).
- (Alistair Stewart): How does this scale to 1000 validators or 16000? Do you have numbers?
- (Michael): can do a reasonable number of epochs, at least a month
- (Psi): multisignature will still take the same amount of time to verify; needing to hash/unhash those...
- (Daira) Expect the verifier to have all the keys?
- (Psi): Yes. Another way to do this: instead of having a bitmask, you'd want to have a proof that aggregate is at least 2/3 majority.
- What properties do you rely on?
- (Michael) Bell-Hopwood is collision resistant, but that's not enough for BLS.
- Composite hash function
- (Youssef El Housni) Is there any plans to use BW6-761 curve instead of SW6? This can make the verifier at least 5 times faster and also the prover
- (Michael): yes, looking into it. Hasn't been done yet because there are fewer implementations.
## Discussion topics
_Suggestions welcome! Please append at the end, and the moderators will incorporate into the schedule._
~15 minutes each, by default.
### Content related to ZKP standardization
- hash-to-curve technique and BLS signature
- recursive composition of SNARKs
- Should verifying signatures inside SNARKs be standardized? Which signature schemes? Should this include specifying a 2-chain of elliptic curves?
(Michael): Something that would be helpful is a standard for verifying signatures. Here we are doing both pairing based sigs, verification, SNARKS need scalar field to have certain properties. May not be the case in other situations
(Dario) For signatures that are friendly in context of verification of SNARKs?
(Dario): in context of hash-to-curve and in signatures, are there are more applications? The application should not be too narrow after all! (Michael): the hybrid hash function would be used anywhere you would use algebraic-flavored hash functions (trade-off for conservativeness vs higher constraint cost.).
(Daira): the way we use signatures in Sapling, we can off-load to a smaller device. Plenty of reasons to standardize SNARK-friendly signatures.
(Dario): What about standardizing the recursive model and Proof-Carrying Data (PCD)? (Michael) what would be standardized; it is not clear. The curves that you want to use are going to vary. (Daira): might be too early to talk about this. There's a recent paper (https://eprint.iacr.org/2020/499.pdf) on formalizing Halo's composition technique.
### Standardizing a formal model for light client
- Does it make sense to standardize a constructive model for forming SNARK-based light clients? If so, does the work presented here seem like a good step in that direction?
- Generalization to other applications