Given the partial success of the previous bounty program and the lack of contributors to the organisation right now. Outlining tasks and offering incentives seems like the best way to bootstrap contributors.
For those not familar with the previous iteration, we saw two independent teams of academics come together to build out the proposed analytics tool bounty; to identify poor usage of the protocol that voids privacy. They named it Tutela, the submission went over and beyond the expectations and requirements. The other bounty was orchestrated around writing in-depth technical documentation for tornado’s low level circuitry, which was partially started but never finalised. Below are several tasks to align contribution and amend inefficiencies in the organisation.
SDK
Difficulty: Medium | Reward: $5,000
Background
Throughout the lifecycle of tornado’s tooling there as never been efforts to undertake easy integration of the protocol. If individuals want to integrate the protocol to applications, they have to execute a tedious workload expanding from defining typechains to handling proof generation.
The benefits of incentivising easy integration of protocol, opens up many possibilities where developers can leverage the protocol to build privacy-perserving applications; such as a wallet. Furthermore it helps individual developers learn the flow of how tornado functions through pre-defined functions and helpers.
Description
Create a Typescript library, to allow the ability to deposit and withdraw to the classic anonymity sets. This includes defining an unique typechain for all the associated parameters.
It is recommended to use websnark to handle proof generation, to not bloat memory requirements for integration. Additionally use the fixed-merkle-tree library to build the deposit tree. Logic for this is already defined in the cli and the classic-ui repositories, applicants should use this as influence or reference.
Deliverables
Submissions are handed by creating a new repository on the community git and submitting the compiled source as a package to npm. Applicants should minimalise unneccesary commits and add clear commentary to each push. Submissions should also be well documentated, describing how to build from source, install and import the package and use each associated functions.
Relayer deployment tutorial
Difficulty: Medium | Reward: $3,000
Background
Relayers are a paramount component of tornado’s functionality in breaking the link between source and destination addresses, a lack of relayers effects the reliability to obtain privacy using the protocol. While it is feasible that the number of relayers deployed is relative to fee capitalisation, and thus withdrawals. The protocol faces contigencies of not fufilling it’s premise if there is a concentration in relayer topology, there should be approachable resources to facilitate onboarding.
Furthermore, the potential risks of operating the relayer software should be outlined alongside recommended methods to veil operations ensuring the ability to maintain the role of a relayer from outside intervention.
Description
Write an indepth tutorial describing a step by step basis of deploying a relayer on multiple or a single network. The document should cover:
- Requirements (software, hardware and costs)
- ENS and DNS configuration
- Relayer deployment on a single network
- Relayer deployment on multiple networks using an nginx proxy
- Privacy perserving deployments using Whonix
There is already minimal documentation on the process of deloyment on the community git’s classic-relayer repository, applicants should use this a basis of influence or reference.
Deliverables
Applicants should adhere to comprehenisble and concise grammar when authoring the guide, and should approach it towards any individuals who don’t have expierence in development or operation systems management.
Submssions are handled by creating a pull-request on the community git’s docs repository.
Discourse Ethereum authentication
Difficulty: Medium | Reward: $1,500
Background
Discourse by default requires operation of an STMP server to authenicate registrations by email, this is not an complimentary process to privacy.
Description
Integrate the possbility of registering and signing into an account on a Discourse instance by connecting an Ethereum wallet, and signing a message. Display the user’s verified address on their forum profile.
Deliverables
Fork the Discourse source code integrate logic to handle a web3 provider, and on registration and sign in require a message to signed to prove owneship of the address in question. Replace email key mappings in the database store with Ethereum addresses. Create a repository on the community git and document the logic thoroughly.
It is recommended to use Ethers.js to approach the handling of provider and message signing but individuals are free to take their own course of implementation if they believe it is more beneficial. It should be not be understated, that implementations that depend on other services are not desirable.
Cli improvements
Batching
Difficulty: Medium | Reward: $2,000
Background
Given how ineffective it is to process multiple deposits or withdrawals with the cli, there is a clear benefit to suport consecutive transactions. Not only would it make the tool more efficient than the frontend but it would incentivise the use of, and strengthen - the lower anonymity sets.
Description
Integrate capabilities to execute multiple deposits to a anonymity set in a single command, and to process multiple withdraws by providing a list of notes.
It is recommended to handle transaction ordering sequentially and ensure confirmation of subsequent transactons is reached sufficiently before broadcasting, each request should be handled as a promise.
Possibility to use the tx-manager package for the basis of handling transaction ordering and settlement.
Deliverables
Applicants should adhere to clean syntax in the integration, and should not modify any other elements of the source code that do not have relevancy to the task. Submssions are handled by creating a pull-request on the community git’s tornado-cli repository.
Applicants should minimalise unneccesary commits and add clear commentary to each push. Submissions should also be well documentated, stating the reasoning behind taking the course of implementation.
Circuit documentation
Difficulty: Hard | Reward: $10,000
Background
Tornado’s low-level circuits are a fundamental component of the protocol’s architecture, given how they are used as a core curriculum matieral in education of zero-knowledge. There should be in-depth commentary of the logic behind each circuit, helping onboarding education.
Description
Author a technical specification of the Circom circuits for Classic and Nova, alongside NATSPEC comments to assist code readability.
Deliverables
Submission of the circuit specifications is handled by creating a pull-request on community git’s docs repository.
Submission of the NATSPEC commentary is handled by creating a pull-request on community git’s tornado-pool and tornado-core repositories, for each associated version of the protocol.
Applicants should adhere to an in-depth technical standard of documentation (higher-level concepts, domain objects etc) in the specification, and follow the NATSPEC guidelines for code commentary.