Knifehead

[porcuquine]

Knifehead / Stage 3 / Public Release

All, please take some time between now and our next scheduled sync to:

• Attach relevant issues (creating new ones as needed) to this epic, which we will continue to use to track progress toward stage 3.
• Add narrative/descriptive text which provides context and inward/outward/laterally-facing information that isn't captured in the GitHub/ZenHub/ epic/issues metadata. The goal is that this page (along with the ZenHub data presented with the plugin — get it if you don't have it — gives a very good overview of what we are working on and how we are doing.

In order for this to work well, we need to keep things up to date — so please do so. This includes periodically revisiting the Plans section. Consider that your space to provide an up-to-date status and plan. Consider using this as a very lightweight log to as key units of work are completed and become past rather than future.

Plans

@schomatis

Working on a cache for the parents and related methods of the ZigZag trait: #455. A good chunk of the time has been invested in understanding the code (particularly the ZigZag and Graph traits and the example currently used to benchmark them). Another part of the time has gone to understand Rust mechanisms to allow to mutate immutable references across multiple threads.

@dignifiedquire

Currently doing some minor things, like improving the Replication Game Server.
Next focusing on accumulators & other possible improvements and possible road blockers for PoRep and PoST with @nicola. Exact order and details of upcoming work in this area will be determined on need basis, and depending on how certain things play out.

@laser + @sidke

Note: We (@laser and @sidke) do not yet know how we will divide up the following work.

We will start Q1 by finishing the libfilecoin_proofs release flow. Our ultimate goal here is to prevent go-filecoin developers from needing to have the Rust toolchain on their machine in order to build go-filecoin. Our first milestone will be that go-filecoin OSX builds will not need to build rust-proofs before building go-filecoin. Our second milestone will be that go-filecoin Linux builds will not need to build rust-proofs before go-filecoin. Our third milestone will be that go-filecoin developers will not need Rust installed on their computer in order to build go-filecoin. At some point, we will need to build tooling which, in the event that go-filecoin can't link against the released staticlib, we fall back to a full rust-proofs build (the status quo as of January 8, 2019).

We will come up with a plan for distributing (and consuming) Groth (proof) parameters. Our current plan is to build some tooling in rust-proofs to facilitate A) creating Groth parameters B) pushing parameters to IPFS and pinning the relevant cid and C) committing some artifacts to our VCS to link a rust-proofs GitHub SHA with some parameters. For go-filecoin, we will need a way to learn the cid of the Groth parameters (on IPFS) and make an HTTP request (to an IPFS gateway) to download the parameters to a place where rust-proofs can consume them. Our Q1 workflow will be rudimentary; rust-proofs developers intending to publish Groth parameters will likely need to interact with IPFS (either through the IPFS binary or through some Bash scripts which we will write) and IRC (for the IPFS pinning-bot).

@laser will work with @porcuquine to determine the rust-proofs/go-filecoin API impact of A) creating file inclusion proofs and B) consuming them in go-filecoin.

We will implement FileSystemByteSource and FileSystemByteSink in both go-filecoin and rust-proofs. A goal for Q1 is to modify the existing add piece flow such that go-filecoin passes to rust-proofs a token which it interprets into a FileSystemByteSource instead of a dynamic byte array. A goal for Q1 is to modify the existing retrieve piece flow such that go-filecoin receives from rust-proofs a token which it interprets into a FileSystemByteSource instead of a dynamic byte array.

@luca [You can remove yourself if you don't want to participate here, but you are also welcome to use this space since you will be participating in our weekly syncs.]

@nicola

@porcuquine

Top of the stack:

• PoSt
• Multiple Sector Sizes
• ZigZag spec

Stuff on my radar, somewhat prioritized:

• Replication performance and real replication parameters in API
• Finish specs generally
• Parameter delivery
• Hardware calculator
• Benchmarks Server [ongoing]
• Piece Inclusion Proof

[porcuquine]

https://docs.google.com/document/d/1wjnjkHHXNH4FYgIrcTpW-HPrkOwDF3ijlM-2Mv-E4JA/edit