A Vector Commitment (VC) is a position binding commitment and can be opened at any position to a unique value with a short proof (sublinear in the length of the vector). The Merkle tree is a VC with logarithmic size openings.

Recent work on RSA-based VC (Boneh et al. 2019) allows for constant size openings as well as aggregatable proofs, which makes it appealing for several decentralized applications (stateless blockchains, proof of storage).

The Filecoin Research team is working on an improving the current protocols to make them more efficient and to construct succinct Proofs of Storage based on RSA-based VC.

The output of this work is to implement a VC library with our latest research and applications to Proof-of-Storage.

Current implementations:

• Cambrian Labs
• @dignifiedquire’s implementation

We use the JubJub Pedersen hash to generate the Merkle trees in Filecoin. The computation of these hashes is slow and CPU-intensive (~200 times slower than blake2s). Reducing the cost of computing Pedersen hashes will reduce the operating costs of mining in Filecoin. Are there cost effective ways to speed up Pedersen hash computation?

The output of this work an improvement to the Bellman Pedersen hash algorithm (implemented here). Amongst possible solutions: GPU programming, SIMD optimizations, FPGA.

The security of Proof-of-Replication (as well as other Proof-of-Space schemes) relies on the best known attacks to Depth Robust Graphs.

An (e,d)-depth-robust directed acyclic graph (DAG) has the property that after removing any subset of up to e nodes (and adjacent edges) there remains a directed path of length d.

The algorithm we are using for generating Depth Robust Graph is based off the DRSample algorithm described by Alwen et. al and BucketSample by Fisch et al. and have been implemented in drgraph.rs. Both papers describe the best known attacks to these graphs.

The output of this work is to implement the current best known attacks in Rust and run them against the DRSample, BucketSample and ZigZag graphs.

Background on PoRep

Proof of Replication is divided in two phases: an offline phase and an online phase.

During the offline (or setup) phase, the prover generates a slow encoding of the data and a proof that the encoding was performed correctly. During the online phase, the prover generates a proof that they are still storing the encoded data.

The speed of replication has both impact on security and scalability.

Why is replication speed important for scalability?

The longer it takes to replicate a fixed unit of storage (say 1GiB), the more computational expensive the computation for the miner.

Why is the replication speed important for security?

The speed of the replication step of PoRep is key to define security in Filecoin. If a malicious prover can replicate much faster than the other nodes, they can attempt generation attacks (generating and replicating data on the spot) and be able to claim more data than they have.

What’s next?

So far, we did our best effort to implement the “fastest” replication algorithm, however there is quite some room of improvement both in software and in hardware.

Software wise, there are several areas still to be improved: better parallelization, and exploiting space/time tradeffs.

We have set up the replication game where you can run your algorithm on your hardware and show up on the leaderboard.