![](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
Authors:
 Ariel Gabizon
 Kobi Gurkan
 Philipp Jovanovic
 Asa Oines
 Marek Olszewski
 Michael Straka
 Eran Tromer
 Psi Vesely
To be presented on 20200504.
Resources:
* [Latest PDF version](https://docs.zkproof.org/pages/standards/acceptedworkshop3/proposalplumo_celolightclient.pdf)
* [Miro Whiteboard](https://zkproof.org/workshop3board)
* [SoK Working Group](https://community.zkproof.org/g/WG_PLUMO)
* [Additional related links](https://hackmd.io/@HtwXZrPTFCniCs7fWFSmQ/B1AwbdI_8)

## Realtime notes
_Note taker: Abida Haque_
> Others are welcome to augment/annotate using notes. Add your name. MyName
Problem statement:
 Problem: Blockchains are big
 How can we make verification easier?
### BLS Verification
Bilinear pairings
Can have a problem of EC computations inside arith ckt, want the ckt defined over scalar field of curve. Actually want 2chain.
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 hashtocurve 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 SPVlike 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.

## Questions
 (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.
 (Daira)
 (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) BellHopwood is collision resistant, but that's not enough for BLS.
 Composite hash function
 (Youssef El Housni) Is there any plans to use BW6761 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.
____
Charter Ideas
Goals:

Milestones:


## 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
 hashtocurve technique and BLS signature
 recursive composition of SNARKs
 Should verifying signatures inside SNARKs be standardized? Which signature schemes? Should this include specifying a 2chain 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 hashtocurve 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 algebraicflavored hash functions (tradeoff for conservativeness vs higher constraint cost.).
(Daira): the way we use signatures in Sapling, we can offload to a smaller device. Plenty of reasons to standardize SNARKfriendly signatures.
(Dario): What about standardizing the recursive model and ProofCarrying 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 SNARKbased light clients? If so, does the work presented here seem like a good step in that direction?
 Generalization to other applications