Rfps brainstorming

rfps/candle-auction.md

@@ -1,6 +1,6 @@
 # Candle auction smart contract
 
-* **Status:** Open
+* **Status:** [In progress](https://github.com/w3f/Grants-Program/pull/666)
 * **Proposer:** [mmagician](https://github.com/mmagician)
 
 

rfps/epassport-zk-validation.md

@@ -0,0 +1,51 @@
+# e-Passport ZK Validation
+
+* **Status:** Open
+
+## Project Description :page_facing_up: 
+
+The issue of verifying identities on-chain and providing Proof-of-personhood is a challenging one.
+
+One idea to authenticate users is to ask them to submit the details from their e-passports. While it would provide authentication, it forgoes the aspect of privacy.
+
+This proposal aims to provide the verifiability of personal data coming from e-passports, while ensuring protection of personal information by using zero-knowledge proofs.
+
+## Deliverables :nut_and_bolt:
+
+Please note that the below given details do not comprise neither detailed nor security-complete plan of development. The implementing party should perform in-depth research on each part of the protocol in order to understand its limitations and nuances.
+
+### Milestone 1 - transparent solution PoC on substrate
+
+* **Estimated Duration:** 3 months (incl. research)
+* **Costs:** 60,000 kUSD
+
+As the first step, we propose the creation of a working PoC without the use of zero-knowledge proofs taht can be deployed on substrate.
+
+Deliverables:
+- Chain can store the necessary certificates from CSCA
+- User can upload their DSO (Document Security Object) as well as the associated DSC (Document Signer Certificate) on chain
+- The chain logic verifies:
+    - DSC is valid against CSCA
+    - the signature contained within the DSO checks out against DSC
+
+### Milestone 2 - adding ZK functionality
+
+* **Estimated Duration:** 5 months
+* **Costs:** 100,000 kUSD
+
+Rather than supplying the entire DSO, which would reveal the user's personal information, users should be able to upload a cryptographic proof that they indeed know the data contained within the DSO, without revealing it in its entirety.
+
+There should be two parts to this functionality: off-chain prover and on-chain verifier.
+
+The users would supply all their private information to the off-chain prover (which they can either run themselves or use a trusted third party) and the prover would produce a cryptographic proof.
+
+Later, the proof is uploaded on-chain, and the chain logic performs verification of the proof given the pre-agreed circuit. The circuit must be shared between prover and verifier and should include public inputs such as the latest [Master List](https://www.icao.int/Security/FAL/PKD/Pages/ICAO-Master-List.aspx) of CSCA certificates, revocations, etc., as well as use the same algorithms and parameters.
+
+### Milestone 3 - Updateability
+
+* **Estimated Duration:** 1 month
+* **Costs:** 20,000 kUSD
+
+The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates.
+
+It is important that both prover and verifier circuits are updated accordingly - else the proof won't match.

rfps/php-scale.md → rfps/implemented/php-scale.md

@@ -1,7 +1,7 @@
 # PHP Version of SCALE Codec
 
 * **Proposer:** [swader](https://github.com/swader)
-* **Status:** [In progress](https://github.com/w3f/Open-Grants-Program/blob/master/applications/php-scale-lib.md)
+* **Status:** [Done](https://github.com/w3f/Open-Grants-Program/blob/master/applications/php-scale-lib.md)
 
 ## Project Description :page_facing_up: 
 

rfps/mixer.md

@@ -0,0 +1,151 @@
+# DOT & KSM mixer
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Polkadot uses an account-based Tx model, which easily enables linking activity between accounts.
+To preserve on-chain anonymity, the options available to the user at the moment are limited to using centralised exchanges.
+It requires transferring their funds to an exchange-controlled account and withdrawing them at a later point in time, to a different account.
+
+While it works to an extent, there are major drawbacks:
+
+* Users need to trust the exchange in the first place
+* There is a fee associated with each transaction, usually both withdrawal and deposit, and sometimes also with creating an account
+* The entire process is cumbersome
+* If the user wants to *mix* the whole amount, analysis tools can still correlate similar-looking values (especially taking the fees into account).
+
+This is where **Smoothie** comes in: giving the user back their privacy.
+
+### Project Details
+
+Conceptually, the project is similar to an Ethereum-based [tornado.cash](https://tornado.cash/). We won't describe the mechanics of that project in this application, but rather outline the differences in implementation and how it will translate to a Polkadot deployment.
+
+1. ZK Proof system
+
+Tornado cash uses a Groth16 proving scheme, whereas Smoothie will leverage a more modern and efficient scheme Plonk.
+The three main advantages of Plonk over Groth16 are:
+
+* Faster prover time
+* Smaller number of circuit constraints[^1](for a concrete circuit proving leaf knowledge in a Merkle tree, which is essential for any mixer), leading to smaller program sizes
+* Trusted setup, while still required, is universal (not relevant for this project)
+
+2. Hash function
+
+The advantage of building an end-product after Tornado is the opportunity to use newer hash functions, too. Specifically, we will be using a Poseidon hash function, which is more suited for ZK proof systems than Pedersen hash used in Tornado, using up to 8x less constraints per message bit [^2]([Poseidon Hash paper](https://eprint.iacr.org/2019/458.pdf))
+
+3. Implementation
+
+While we could build the smart contract with solidity and deploy on an EVM-compatible parachain, we believe that using a rust-based smart contract language brings unquestionable security benefits to the table.
+
+There are Rust-based implementations already available of both [Plonk](https://github.com/dusk-network/plonk) and [Poseidon Hash](https://github.com/dusk-network/Poseidon252/). The challenge will be integrating these into an `ink!` contract.
+
+Most importantly the Dusk lib uses custom data structures, that will need to be:
+ - initially for testing, wrapped in local data structures and have the Spread/PackedLayout derive'd on them (due to the orphan rule you can't have non-local both struct and derive macro)
+ - later, for optimisation, custom PackedLayout needs to be implemented for taking advantage of efficient storage
+
+
+Aside from the core of Smoothie (smart contracts), there are two more critical components to make it fully functional:
+1. Tx Relayer: the whole idea of a mixer is that the withdrawing account can't be linked to the deposit account. This means withdrawing from an empty account which can't cover its Tx fees. This is where the relayer comes in: a user would generate the proof in the frontend portal with their own payout address and relayer's fee address as parameters, so that the relayer can't steal the funds. The relayer submits the Tx to the smart contract, which, upon verifying the correctness, would pay the amount to the user and a subtract the fee for the relayer.
+2. Frontend: users should have a friendly interface (akin to Tornado.cash) to:
+  - create commitments and submit them to the mixer. They should be presented with a "note" that allows them to withdraw the amount later
+  - select the relayer
+  - spend the notes, by submitting the necessary data to the smoothie contract for it to verify the ownership of the deposited coin
+
+### Ecosystem Fit
+
+The project closest to ours is [anon](https://github.com/webb-tools/anon). They are building a mixer as a substrate module as opposed to smart contracts. Furthermore, they are utilizing the Bulletproofs system in contrast to Plonk.
+
+## Team :busts_in_silhouette:
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+* **Total Estimated Duration:** 6.5 months
+* **Full-Time Equivalent (FTE):**  1
+
+
+### Milestone 1: MerkleTree implementation and contract template
+
+* **Estimated duration:** 0.5 month
+* **FTE:**  1
+
+1. Implement an append-only `MerkleTree` struct on 32-byte arrays as leafs, that can be imported into an `ink!` contract. Use an `ink!` built-in hash function (Blake2x256) for now.
+2. Create an `ink!` contract with `deposit` function, that uses the MerkleTree as the underlying data storage and appends the commitments "deposited" to it.
+3. Add the signature for the `withdraw` function. Verify that the submitted nullifier hash hasn't been "spent" yet.
+4. Emit the `Deposit` and `Withdraw` events.
+
+### Milestone 2: Integrate Poseidon hash into Smoothie
+
+* **Estimated duration:** 0.5 month
+* **FTE:**  1
+
+Replace Blake2x256 with [Poseidon](https://github.com/dusk-network/Poseidon252/) hash algorithm.
+
+### Milestone 3: Plonk prover CLI tool (compiles to WASM)
+
+* **Estimated duration:** 2 months
+* **FTE:**  1
+
+Create a CLI tool that takes as inputs:
+- the prover key `d_p`(hardcoded for now; later generated from a trusted setup ceremony)
+- leaf index `l`
+- the merkle tree opening for leaf `l` and a root `R` from history
+- nullifier `k`
+- randomness `r`
+- payout address `A`
+- relayer address `t`
+- relayer fee `f`
+
+And produces a ZK proof `P`. The tool can be compiled to WASM for future inclusion in the frontend component.
+Utilise [Dusk's Plonk implementation](https://github.com/dusk-network/plonk) as much as possible.
+
+### Milestone 4: `withdraw` method & Plonk verifier in `ink!`
+
+* **Estimated duration:** 2 month
+* **FTE:**  1
+
+To withdraw a coin, a user needs to submit a proof that they know the randomness & nullifier, i.e. they are the true owners of the coin.
+The `withdraw` method of the mixer ensure that the nullifier `k` has not been spent yet (by storing the previously spent nullifier hashes).
+Critically, the method delegates the checking of the proof to the verifier (another method), which takes as inputs:
+- the verifier key `d_v` (hardcoded for now; later generated from a trusted setup ceremony)
+- ZK Proof `P` generated by the prover
+- Root `R`
+- hash `h` of the nullifier `k`
+- payout address `A`
+- relayer address `t`
+- relayer fee `f`
+
+It returns true if the proof `P` satisfies the public values (the rest of the inputs)
+Utilise [Dusk's Plonk implementation](https://github.com/dusk-network/plonk) as much as possible.
+
+### Milestone 5: Relayer
+
+* **Estimated duration:** 0.5 month
+* **FTE:**  1
+
+An offline tool (written in Rust or TypeScript, TBD) that is pre-funded and accepts incoming requests.
+It verifies the validity of the submitted proof & Tx. If correct, it submits the Tx to the smoothie `ink!` contract.
+
+Also here we will write out the smart contract logic for paying out the fee `f` to relayer address `t`, once a valid Tx has been submitted. This will fall under the `withdraw` method.
+
+### Milestone 6: Frontend
+
+* **Estimated duration:** 1 month
+* **FTE:**  1
+
+### Milestone 7: Trusted setup ceremony (optional)
+
+* **Estimated duration:** 0.5 month
+* **FTE:**  1
+
+## Future Plans
+
+1. Supporting arbitrary tokens
+2. ?? Wallet ??
+3. Incentive layer with Smoothie token: This is akin to Tornado.cash's TORN token. This is not strictly necessary for the functioning of the project, but it serves in users' best interest. The longer they keep the tokens in the smart contract (a.k.a anonymity pool), the more Smoothie they accumulate, thus keeping a high anonymity set and preserving privacy. This is also the most likely way to monetize the project, e.g.:
+  - 10% allocated to the founding team
+  - 20% for early investors
+  - 20% for public sale
+  - 50% for anonymity pool

rfps/multi-chain-block-explorer.md

@@ -0,0 +1,13 @@
+# Multi-chain Block Explorer
+
+* **Status:** Open
+* **Teams/People that could deliver the RFP:** @clearloop, @carlhong
+
+## Project Description :page_facing_up: 
+
+As parachains become an integral part of the Polkadot and Kusama ecosystems, a cross-chain block & accounts explorer becomes all the more useful.
+
+Some of the functionality that should be covered as part of the development:
+- select which chains to view (e.g. default when selecting Kusama is Kusama relay + all its parachains). Should be feasible to select alternative mainnets too.
+- input an address and see Tx's on all the selected mainnets, including teleports/XCMs between various parachains
+- when a Tx includes a XCM, it should be easy and intuitive to open the relevant block from the other chain(s).

rfps/php-api.md

@@ -1,7 +1,7 @@
 # PHP Substrate API
 
 * **Proposer:** [swader](https://github.com/api)
-* **Status:** Open
+* **Status:** [In progress](https://github.com/gmajor-encrypt/php-substrate-api)
 
 ## Project Description :page_facing_up: 
 

rfps/polkadot-collator-setup.md

@@ -0,0 +1,39 @@
+# Polkadot Collator Setup
+
+* **Status:** Open
+* **Proposer:** mmagician
+* **Your Project(s):** https://mmagician.github.io/
+* **Projects you think this work could be useful for** Any parachain team
+
+## Project Description :page_facing_up: 
+
+This is meant as a companion repository to [polkadot-validator-setup](https://github.com/w3f/polkadot-validator-setup), which allows anyone to launch a validator node in an automated and secure fashion.
+
+I would like to standardize (as much as possible) the process of spinning up new collator nodes for different parachains.
+
+I understand it might be tricky to bundle all the parachain launch setups into one repository, but there are some ideas of how this can be tackled:
+1. Have a single collator ansible role, and each branch would correspond to a specific parachain
+2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed.
+
+I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much.
+
+## Deliverables :nut_and_bolt:
+
+Ideally the PoC would 
+Please list the deliverables of the project in as much detail as possible. Please also estimate the amount of work required and try to divide the project into meaningful milestones.
+
+* **Total Estimated Duration:** Duration of the whole project
+* **Full-time equivalent (FTE):**  Amount of time (in days) required for a single person to complete this project ([see](https://en.wikipedia.org/wiki/Full-time_equivalent)) 
+* **Total Costs:** Amount of Payment in USD for the whole project. 
+### Milestone 1
+
+Please add additional milestones in the same way: 
+* **Estimated Duration:** Duration of milestone 1 
+* **FTE:**  Amount of time (in days) required for a single person to complete this milestone
+* **Costs:** Amount of Payment in USD for milestone 1
+
+
+| Number | Deliverable | Specification | 
+| ------------- | ------------- | ------------- |
+| 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible |  
+| 2.  | ... |...| 

rfps/raft-validators.md

@@ -1,6 +1,6 @@
 # High-availability validator setup
 
-* **Status:**
+* **Status:** Open
 * **Proposer:** mmagician
 * **Projects you think this work could be useful for:** Polkadot & Kusama Validators
 

rfps/validator-setup-maintenance.md

@@ -0,0 +1,19 @@
+# polkadot-validator-setup maintenance
+
+* **Status:** Open
+* **Teams/People that could deliver the RFP:** @melozo, @pmensik, @tylerztl, @bLd75
+
+## Project Description :page_facing_up: 
+
+One of the more accessible ways of spinning up validator nodes is by using the [`polkadot-validator-setup`](https://github.com/w3f/polkadot-validator-setup) repository, which uses a mix of terraform and ansible tools to create a server, adjust its configuration and install the necessary packages needed for running a substrate node.
+
+This RFP aims at providing maintenance to that repository and add some small features.
+
+## Deliverables :nut_and_bolt:
+
+A list of possible tasks to work on:
+- fixing issues and improving documentation
+- updating any libraries/deps needed
+- support additional terraform backends to store the terraform state (currently only `gcp`, could add `s3`: see [this issue](https://github.com/w3f/polkadot-validator-setup/issues/108) and local storage or even git - it should be discouraged in prod but very useful for testing). See also [this issue](https://github.com/w3f/polkadot-validator-setup/issues/7)
+- investigate pass-phrased ssh key deployment: [issue 109](https://github.com/w3f/polkadot-validator-setup/issues/109)
+- add additional cloud providers to terraform: [alicloud](https://github.com/w3f/polkadot-validator-setup/issues/111), [OVS](https://github.com/w3f/polkadot-validator-setup/issues/116)