# RFP Proposal: ZFile - Paying for Filecoin storage in ZEC

**Name of Project:**
ZFile - A PoC for Paying for Filecoin storage in ZEC

**Link to RFP:**
[Zcash And Filecoin](https://github.com/filecoin-project/devgrants/blob/master/rfps/zcash-and-filecoin.md)

**RFP Category:**
`core-dev`, `technical-design`

**Proposer:** [@eigerco](https://www.eiger.co/)

**Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes

## Project Description
We are directly responding to this [Call For Proposals](https://ff-ecc-grants.org/), in particular the **Filecoin storage payments in ZEC**, which enables the same level of privacy for storage purchases that exists in Zcash shielded transfers.

**GOAL:** ENABLE FILECOIN USERS TO PRIVATELY PAY FOR STORAGE

The global demand for data storage continues to increase, but the majority of it is stored on centralized servers controlled by a limited number of providers, which presents security and reliability issues. Decentralized storage solutions, such as Filecoin, offer a more secure alternative by distributing data across a network of computers, reducing the risk of failure.

While Filecoin provides a decentralized storage solution, it does not offer privacy for transactions. On the other hand, Zcash offers private transactions. We propose to combine the main strengths of these two technologies, and enable any Zcash account holder to pay for Filecoin storage privately, without ever interacting with Filecoin directly.

Our aim is to conduct research, in a reasonable timeframe, on the best possible ways to reach our goal, as well as provide a reference implementation to make it possible for even non-developer Filecoin Users to offer this service on the blockchain.

We want to highlight that anything in this proposal is negotiable and up for discussion.

## Technical description

### Motivation

Zfile is the simplest solution we found, where the assumptions are

- We cannot use a bridge, since Zcash doesn't (yet) support smart contracts
- Trusting a third party to perform a service for us, in a decentralized environment, is hard. Even under the threat of slashing funds.
- What is easier though, is to have an entity acting as intermediary for the payment.
- The Escrow will be controlled by the entity developing the infrastructure during testing, from which it will be assigned to a DAO composed by both Zcash and Filecoin community members, once ready for production.
- The source for currency exchange information could be a decentralized oracle, e.g. [ChainLink](https://chain.link).

### Interaction summary

The implementation we are proposing consists in having an intermediary (the “Provider”) who will take the place of the User as the entity uploading the file to the Network (Filecoin). As for the payment, the user will send a deshielding transaction on the Zcash network, which will hide the origin but show the content of the memo. The whole process will be insured and orchestrated by an Escrow Actor, which will be controlling the ZEC involved in the payment. This is all possible thanks to the FEVM deployed at the moment of writing.

One of the distinguishing features of this proposal, benefiting both Filecoin and Zcash economy, is the possibility for everyone to become a Provider for this service, independently deploying the infrastructure, and asking for a fee in return.

### Roles involved

- The **User** is the entity willing to pay a premium for privacy on Filecoin to store a Binary. For example, a person wanting to publish something without getting recognized. Satoshi Nakamoto could have used this, for example!
- The **Escrow Actor** is the entity acting as gateway for the payment. It orchestrates the payments between the **User** and **Provider**, by way of checking on-chain conditions. It is also the only entity in the protocol having off-chain access, so it controls source of market data, and it also has programmatic access to its own ZEC address.
- The **Provider** is another entity, storing the Binary for the **User**. It acts as an intermediary for the storage on-chain, i.e. it will figure that all files stored on-chain through the Provider belong to the Provider itself.
- The **Provider's On-Chain Actor** (POCA) orchestrates the storage for the **Provider**, who will be able to choose among different versions the most apt to them, and deploy it.
- The **Blockchain** is the Filecoin blockchain, mainnet or testnet. This entity represents all other on-chain information which is not contained in the other two actors.

### Provider Setup
To become a provider and start earning on storage requests, one must:

1. Put in place the necessary infrastructure which brings the files to the chain and handles the payment. For example, a website with an upload form.
2. Own a transparent Zcash address.
3. Deploy a POCA with a stake of FIL. This stake will represent locked funds that act as guarantee for bad behaviour from the Provider's side.
4. The POCA has to possess at all times enough FIL to manage the load of files, which the Provider promises to handle. Any mishaps will result in slashing, which may be contested with the Escrow Actor's owners.

The locked funds (or collateral) will be proportional to the amount of bytes the Provider can process per each time frame. The Provider can increase or decrease the locked funds every n blocks, with a minimum limit set. An alternative to this mechanism could be also the [Collaterals](https://spec.filecoin.io/#section-glossary.collateral) used by Storage miners on Filecoin or a variation of it. This is all at discretion of the implementers.

### Exemplary steps to store a file on-chain

<br/>

<figcaption>Fig. 1: a bird's eye view for the whole storage procedure</figcaption>

<br/>

0. The User has a file to store (encoded or not), but they want to remain anonymous when storing and retrieving the file. They have ZEC to spend for this, and no FIL.
1. The User wants to stay anonymous, but the transaction destinatary should be public. The solution for this is broadcasting a Deshielding Transaction to the Escrow Actor address (which shall be publicly available and transparent). The memo of the Tx will contain the File checksum and the spacetime parameters for storage.
2. The User transmits _in some way_ the file to store to the Provider of choice. "In some way" means that this can happen in any way digitally possible, but imagine a form with an upload field. Or sending a link to another service. The provider in this step should obtain the file content as binary. This step is implemented at discretion of the Provider.
3. The Provider will Request a Bid Order for the File. From this point on, the responsibility to get the binary on the chain is solely the Provider's. It will send the file and all the parameters.
4. The POCA will send a Bid Order with the appropriate parameters.
5. The POCA will store the confirmation ID and all the appropriate information from the chain.
6. The POCA will send to the Provider the storage confirmation, or the Provider will get it by polling (depending on the communication direction implemented).
7. Request ZEC payment to the Escrow Actor.
8. The Escrow Actor will have to confirm that the storage actually proceeded, with parameters requested by the User, including but not limited to the steps shown in the diagram.
9. The Escrow Actor will immediately release ZEC payment to the address indicated by the provider
10. The Escrow Actor will publicly notify the User that the storage proceeded successfully.

<br/>

<figcaption>Fig. 2: An exemplary topology of multiple deployed providers communicating with the same Escrow Actor</figcaption>
<br/>

### Sidenotes
* The file will not be manipulated in any way on-chain, so if the User wants to have it encrypted, they will have to encrypt that before it is brought to a Provider.
* The Escrow will control the ZEC address for example through an API or a future Actor on-chain. This step has security implications and a (at least partially) definitive answer is to be given by an interaction between the implementers and the Filecoin community in the first milestone phase.
* The User will bear the fees and the transaction cost. That means they will need to pay:
- Zcash transactions both ways from the Escrow actor. (2x Zcash transaction)
- Fees for the Provider (which could even charge 0, as it desires)
- ZEC equivalent of FIL used for the storage according to the most suitable Oracle, provided by the Escrow Actor, at the moment of storage.
- Fee for “previewed” fluctuation, computed and provided by the Escrow Actor at a given moment in time.
* The purpose of having an On-Chain actor deployed by the provider is to have most of the procedure automatized and have an additional security gate, which keeps a set of approved/tested methods and a trusted state.
* A first set of approved contracts will be developed internally as a PoC, but we see it as a possibility for open contribution. We could offer the possibility for anyone to propose a new "candidate" Approved Contract, and after review by the responsible party (the future Escrow DAO), it could become an Approved Contract.
* There will be a timeout time under which the provider has to complete the storage procedure.
* The 6th and the 7th step could be a unique step, at the Provider's discretion.
* The (8) step is probably the most critical part because it's the step where a malicious actor could try to steal from the pool. These are some suggested steps:
- If the actor bytecode is in the approved list, go forward
- The payment request should contain the File checksum and the “alleged” CID which are bound to each other. This association should be contained in the Actor state as well, for permanent reference.
- The CID and the checksum are stored in the Actor, which will calculate that before storing on the Chain, so we can trust the Actor without downloading the file to verify the checksum
- The CID will have associated Spacetime storage parameters, visible publicly on the blockchain
- If all the steps above agree, the payment may be immediately released.
* Since the User is private, the Escrow Actor cannot know of course of any email or such. So, the storage results will be published publicly, for example relating the transaction id to a CID on-chain or on a public page
* Oracles source should be "enforced" by the Escrow Actor to the POCA, or hardcoded in the POCA source file.

### Future DAO Organization

The FVM enables the creation of [DAOs](https://docs.filecoin.io/developers/smart-contracts/filecoin-virtual-machine/#data-dao). We would suggest that after developing a version good for production, the ownership of the Escrow Actor should be transferred to an on-chain DAO. It should be composed by members of the Filecoin community and Zcash community.

To take this one step further the deployment, execution and operation of the Escrow service and the DAO can be democratized so that it becomes very easy for anyone to run this service and for an economy of competing escrow services to spring up. Users will then be able to choose the service of their choice based on reputation or past experiences.

## Development Roadmap
>Please break up your research or development work into a clear set of 2-3 milestones.
For each milestone, please describe the software functionality that we can expect after the completion of each milestone. This should be detailed enough that it can be used to ensure that the software meets the RFP scope.

The development roadmap includes a phase of research where we do an initial viability study and direct eventual questions to the Filecoin community.

We will also make questions on security. What are possible attacks from any side, and how can we protect ourselves from them?

The following months will be the actual development of a PoC and the deployment of an examplary infrastructure on a testnet. There might be nodes created especially for this PoC.

### Milestone 1 - Research and Preparation

**Estimated duration:** 2 months
**FTE:** 4
**Costs:** 211 200 $

**Goals:**
* Research the technologies and Go/Rust/Solidity libraries that could be used when developing an MVP.
* Find their advantages and drawbacks.
* Prepare charts and benchmarking results for objective comparison.
* Develop a few smaller scale demos to better understand the potential results of different technologies.
* Determine the full scope of the project and the required amount of effort needed to have an MVP ready.
* Research the infrastructure needed to run the MVP of the project and determine the steps needed to scale that to accommodate the final ‘production’ version.
* Gather more knowledge about Filecoin and ZCash, and the potential limitations that might require certain workarounds to be developed. In addition to that, determine whether those workarounds can be suggested/contributed to either/both of the aforementioned protocols.
* Research the potential security limitations and attack vectors, especially in the layers dealing with file uploading and checksum verification.

**Requirements for Evaluation:**
* A well-formatted document should be used for research results.
* All research findings should have detailed explanations of steps taken to reach a certain conclusion.
* Charts and data tables should be used to present research data (both inputs and outputs).

**Evaluation Plan:**
* Internal feedback from other developers with relevant experience.
* External feedback from the Filecoin/ZCash community.

### Milestone 2 - Developing Components Needed for an MVP

Estimated duration: 2 months
FTE: 4
Costs: 211 200 $
Note: sub-milestones are meant to be reached while working in parallel, i.e., two teams will be working at the same time.

#### Milestone 2.1 - Developing a Provider MVP

**Goals:**
* Implement the core features needed to run the Provider process:
* Handling of new files uploaded by the User.
* Sending of Bid Order Requests to Provider On-Chain Actor (POCA).
* Handling of storage confirmation events by:
* Listening for confirmation events from POCA.Efficiently polling the data from POCA.
* Requesting and handling of ZEC payments.
* Write proper unit tests for all core features and have high code coverage.
* Prepare reasonable mock services of Escrow and Provider On-Chain actors.
* Have solid code conventions in place.
* Prepare CI/CD jobs for testing, listing, and building.
* Prepare a Dockerfile for cross-platform usage.

**Requirements for Evaluation:**
* Tests should be passing and have reasonably high code coverage.
* It should be possible to build an executable without errors/warnings and run it in a Docker container with mocked actor services.
* It should be possible to build an executable without errors/warnings and run it in a Linux-based environment with mocked actor services.
* CI/CD should be able to produce expected results (e.g., run tests and show the results in the code repository).

**Evaluation Plan:**
Feedback from internal/external developers with relevant experience.

#### Milestone 2.2 - Developing an Escrow and Provider On-Chain Actors

**Goals:**
* Implement the core features needed to run the Escrow Actor:
* Handling of Deschielded ZEC transactions.
* Sending storage confirmation events.
* Validation of Provider On-Chain Actor’s version and other metadata.
* Validation of the uploaded file’s checksum and Order Bid’s spacetime parameters.
* ZEC payment sending.
* Implement the core features needed to run the Provider On-Chain Actor:
* Handling of Bid Order Requests.
* Bid Order sending to the Filecoin blockchain.
* Handling of CID events.
* Sending storage confirmation event (or responding to a request of this nature) to the Provider.
* Sending a valid version and other metadata to the Escrow Actor.
* Write proper unit tests for all core features and have high code coverage.
* Prepare a reasonable mock service of the Provider.
* Have solid code conventions in place.
* Prepare CI/CD jobs for testing, listing, and building.
* Prepare a Dockerfile for cross-platform usage.

**Requirements for Evaluation:**
* Tests should be passing and have reasonably high code coverage.
* It should be possible to run the actors in a test environment (testnet) with a mocked Provider service.
* CI/CD should be able to produce expected results (e.g., run tests and show the results in the code repository).

**Evaluation Plan:**
Feedback from internal/external developers with relevant experience.

### Milestone 3 - Connecting the MVP Parts into One
**Estimated duration:** 2 months
**FTE:** 4
**Costs:** 211 200 $

**Goals:**
Remove mock services/paths/data and connect the Actors and the Provider to each other.
Test whether everything works as expected together and fix/improve areas that are making the system deviate from the expected path.

**Requirements for Evaluation:**
Everything should be working as expected (outlined in the research stage) during manual testing.

**Evaluation Plan:**
Feedback from internal/external developers with relevant experience.

### Documentation, Education, and Community
>Specify your plans for any documentation, education, and/or community-building that will be essential to your project's success.

There will be documentation to understand the various parts of the architecture, a FAQ updated after each development cycle.

We will keep the community updated via Slack/Discord on the progress and with measure, respond to eventual questions. We regard the community as essential to the best possible outcome for the present endeavor.

### Other Deliverables

We will document our research progress and release it to the community to understand how the work come into being and the reasoning behind architectural decisions.

### Milestone Summary

| Milestone | Milestone Description &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Funding &nbsp;&nbsp; | Estimated <br /> Timeframe |
| ------------ | ---------------------- | --------------- | -------- |
| Milestone #1 | Research and Preparation | 211 200 $ | 2 months |
| Milestone #2 | Developing Components Needed for an MVP | 211 200 $ | 2 months |
| Milestone #3 | Unifying the MVP parts | 211 200 $ | 2 months |

### Total Budget Requested
The rate for a Senior developer at Eiger is 150 $/hr per developer.

Total estimated duration: 6 months (24 weeks)

The total rate for 24 weeks with 5 working days for 8 working hours, for four developers:

633 600 $

Since this is a joint grant proposal between the Filecoin Foundation and the Electric Coin Co. , it is expected that the total cost will be split between ECC and FF in a way they best see fit.

## Maintenance and Upgrade Plans
> Specify your team's long-term plans to maintain and improve this project over time.

Once the work under the scope of this grant is completed, we would like to discuss further maintenance or expansion through a further grant application. For example, we could convert the Actors written in Solidity for the FEVM to WASM Actors for the FVM, once it will be released on the testnet.

Another upgrade could be research and implementation for a network with multiple Escrows, with the model mentioned under "Future DAO Organization".

Moreover, we would like this grant application to be considered as a half of a full plan, where the continuation would be the next-in-line functionality mentioned on the website for [FF-ECC grant proposals](https://ff-ecc-grants.org/), "Media and file support in Zcash encrypted memos and NFTs", which would in fact use the technology developed in the present grant proposal.

## Team

The promise of web3 is to upgrade the very foundations of our society – from money, finance, and governance to media, gaming, and science. To deliver on that promise, decentralized technologies are to be integrated into the everyday experiences of billions of people. For engineering, this is a mountain of a challenge.

Eiger was founded to develop infrastructure for web3 mass adoption. We help technology companies improve and integrate the core technologies of web3 to meet the climbing demands for scaling and performance.

We currently employ 25+ senior web3 engineers across the globe and work with some of the most ambitious organizations in the industry, including Forte, Aleo, and XRP Labs, to name a few.

Eiger is part of Equilibrium Group, a blockchain powerhouse founded in 2018, composed of three entities:

**Eiger** – high-value engineering services
**Equilibrium Labs** – applied research, proprietary products, investments in early-stage ventures
**Membrane Finance** – infrastructure and services for EUROe, a euro-backed stablecoin

### Contact Info
> Provide us with a way to contact you (email is probably easiest). You can also email [e-mail] with your GH username and link to your public proposal.

- [e-mail] (Main author of this application)
- [e-mail] (Founder & CEO of Eiger)

### Team Members

The Proof of Concept will be written using Rust and Solidity. We can provide Senior developers in both technologies.

#### Development team
- Eloy ([Github](https://github.com/eloylp), [LinkedIn](https://www.linkedin.com/in/eloylp/)) is a Cloud Software Engineer with extensive experience in Rust and Go, with a focus on observability and resilience. He likes to collaborate in blockchain-related projects as well in distributed, high traffic cloud environments.
- Daniel Zduniak ([GitHub](https://github.com/zduny)) is a Software Engineer having diverse experience in software development industry ranging from a position as a software engineer for a large local manufacturing plant, helped develop real-time interior design visualization software at a small start up company, and lately worked on an open-world video game using Rust for its traffic system.
- Lauri Peltonen ([Github](https://github.com/microbecode), [LinkedIn](https://www.linkedin.com/in/lauri-peltonen)) is a blockchain developer at Equilibrium. He has been working on EVM-based blockchains for 5 years and some 15 years in more traditional IT development. Nowadays he builds mostly EVM dapps in Solidity and does Zero Knowledge research. You can spot him in quite many Ethereum Layer 2 Discords as well.
- Jani Anttonen ([GitHub](https://github.com/JaniAnttonen), [LinkedIn](https://www.linkedin.com/in/janttonen/)) is a Software Engineer at Equilibrium Labs. He has well over a decade of experience in web development, plus Solidity/dApp development as long as DeFi has been a thing. An experimenter at heart, lately he’s been involved in developing a multisig wallet for Starknet.

#### Advising team
- Luca Campobasso ([GitHub](https://github.com/MeerKatDev), [LinkedIn](https://pl.linkedin.com/in/luca-campobasso)) is a Software Engineer at Eiger. He has extensive experience with functional languages (7 years), especially with Scala and Elixir, mostly focused on backend systems design. He conceptualized the described protocol.
- Niklas Long ([GitHub](https://github.com/niklaslong), [LinkedIn](https://www.linkedin.com/in/niklaslong)) deeply cares about open source, distributed systems and data privacy. He has been on the Aleo Core Team since late 2020, mostly overhauling, testing and profiling their network; he is the author of [Ziggurat](https://equilibrium.co/projects/ziggurat) and an active contributor to Rust IPFS.
- Vesa-Ville ([Github](https://github.com/vvp), [Twitter](https://twitter.com/vvpiiroinen/)), the CTO at Equilibrium, has decades of experience in distributed systems, databases and interoperability solutions. His latest projects involve privacy-oriented L1s, ZK proof systems and BFT protocol development. As former co-founder of Haja Networks, he studied the atomic cross-chain composability problem and developed Ambients for executing strongly confluent distributed programs.
- Mark ([GitHub](https://github.com/aphelionz), [Twitter](https://twitter.com/aphelionz)) is the VP of Engineering at Equilibrium. He has led the team starting with the original Rust IPFS grant in late 2019, through engagements with many of the largest names in Web3, and is now circling back to finish the critical work the team started with the original Ziggurat proposal. Core contributor to OrbitDB, Rust IPFS, and Ziggurat.

### Team Website

Main implementer: Eiger https://www.eiger.co/
Tech & Knowledge support: Equilibrium https://equilibrium.co/

## Relevant Experience and repositories
> Please describe (in words) your team's relevant experience, and why you think would do a great job with this RFP. You can cite your team's prior experience in similar domains, doing similar dev work, individual team members' backgrounds, etc.

As mentioned in the Teams section, Eiger has already a large amount of experience in developing large infrastructural project. Some chosen examples:

- The [SnarkVM](https://github.com/AleoHQ/snarkVM) and [SnarkOS](https://github.com/AleoHQ/snarkOS) for Aleo, the privacy focused smart contract L1 platform going live this summer.
- [OrbitDB](https://github.com/orbitdb/orbit-db), a distributed, p2p, serverless database.
- The rust implementation of [IPFS](https://github.com/rs-ipfs/rust-ipfs), now archived.
- The main implementation of [Internledger](https://github.com/interledger/interledger-rs) in Rust, which we are developing and actively maintaining.
- [Ziggurat](https://github.com/runziggurat). Network protocol testing framework for ZCash, XRP and Algorand. Notably, critical network vulnerabilities were found and reported to the core teams.

Moreover, Eiger is already a recipient of a [Zcash Foundation grant](https://forum.zcashcommunity.com/t/zcash-uniffi-library-rfp/43468), whose [implementation](https://github.com/eigerco/uniffi-zcash-lib/) is at the time of writing under way.