Contributing

How to get started

Every monday 16:00 CET, there is our main dev meeting on our chat. Feel free to join and discuss with other darkfi devs.

In general, the best way to get started is to explore the codebase thoroughly and identify issues and areas of improvement.

Contribute according to your own interests, skills, and topics in which you would like to become more knowledgable. Take initiative. Other darkfi devs can help you as mentors: see the Methodology section of the Study Guide.

Few people are able be an expert in all domains. Choose a topic and specialize. Example specializations are described here. Don't make the mistake that you must become an expert in all areas before getting started. It's best to just jump in.

Finding specific tasks

Tasks are usually noted in-line using code comments. All of these tasks should be resolved and can be considered a priority.

To find them, run the following command:

$ git grep -E 'TODO|FIXME'

Areas of work

There are several areas of work that are either undergoing maintenance or need to be maintained:

Documentation: general documentation and code docs (cargo doc). This is a very important work for example overview page is out of date.
- We need a tutorial on writing smart contracts.
TODO and FIXME are throughout the codebase. Find your favourite one and begin hacking.
- DarkIRC encrypted DMs to nonexistant users should not be allowed.
- Currently closing DarkIRC with ctrl-c stalls in p2p.stop(). This should be fixed.
- Add log = path and log_level = debug config setting to DarkIRC
Tooling: Creating new tools or improving existing ones.
- Improve the ZK tooling. For example tools to work with txs, smart contracts and ZK proofs.
- Also document zkrunner and other tools.
Tests: Throughout the project there are either broken or commented out unit tests, they need to be fixed.
Cleanup: General code cleanup. for example flattening headers and improving things like in this commit.
Python bindings: Help ensure wider coverage and cleanup the Python bindings in src/sdk/python/.
- The event graph could have Python bindings but involves some tricky part integrating Python and Rust async.
Events System: See the event graph system. We need extra review of the code and improvement of the design. This is a good submodule to begin working on.
DHT: Currently this is broken and needs fixing.
p2p Network: this is a good place to start reviewing the code and suggesting improvements. For example maintaining network resiliency. You can also look at apps like darkirc, and the event graph subsystem, and see how to make them more reliable. See also the task manager tau.
- Implement resource manager. See its implementation in libp2p for inspiration.
- Improve hosts strategy using a white list, grey list and black list. See p2p Network: Common Mitigations item called White, gray and black lists.
Harder crypto tasks:
- DAO note verifiable encryption
- Generalize DAO proposals by committing to a set of coins rather than a single one.
- Add proposal_type field and proposal_data.
- Money viewing keys
- Method to export_public_inputs(calldata, "public.json")
Eth-DarkFi bridge or atomic swaps. Atomic swaps is probably better since it's trustless and p2p.

Mainnet tasks

Tasks are in no particular order. Use common sense.

Finish darkfid with PoW and research and implement XMR merge mining
Make darkfi-mmproxy stable and implement what is needed for DarkFi x Monero merge mining
Finish dnetview
Make eventgraph stable and implement proper unit and integration tests
- Unit tests should test pieces of the eventgraph code
- Integration tests should simulate a P2P network and ensure deterministic state after a simulated run
- Update https://darkrenaissance.github.io/darkfi/misc/event_graph/event_graph.html and make it the specification for the eventgraph implementation implementation
Rework drk (the wallet CLI) to work standalone and make it work with the new darkfid
Make tau stable
Make darkirc stable
Make lilith stable, there is currently some bug that causes connection refusals
Implement transaction fees logic
Implement contracts deployment logic
Revisit all the code inside src/runtime/ and make sure it's safe
Implement verifiable encryption for DAO payments
DAO should be able to perform arbitrary contract calls, it should act as a voted multisig
Implement cross-chain atomic swaps (XMR, ETH, anything applicable)
Rework the connection algo for p2p to use black list, grey and white list
- https://eprint.iacr.org/2019/411.pdf (Section 2.2)
- See also P2P Network: Common Mitigations
Create a P2P stack test harness in order to be able to easily simulate network behaviour
- Possibly we can create a dummy p2p which can simulate network connections and routing traffic. We can use this to model network behaviour.
Implement address/secretkey differentiation
- See WIF
Fix bugs and issues in the DAO implementation
Perform thorough review of all contracts and their functionalities
Randomize outputs in Money::*, and potentially elsewhere where applicable
- This is so the change output isn't always in the same predictable place, and makes identifying which output is the change impossible.
Document contracts in the manner of https://darkrenaissance.github.io/darkfi/arch/consensus/stake.html
Serial used in money coins
- One solution is: don't accept coins with existing serial in drk.
- We should construct a scheme to derive the serial, evaluate how simple changing the crypto is.
- Malicious users could send you a coin which is unspendable. A poorly implemented wallet would accept such a coin, and if spent then you would be unable to spend the other coin sharing the same serial in your wallet.
Separate mining logic from darkfid into a new program and communicate over RPC
resource manager for p2p (DoS protection, disconnect bad nodes)

Task #	Assignee
1.
2.	`brawndo`
3.
4.
5.
6.
7.
8.	`brawndo`
9.	`brawndo`
10.	`brawndo`
11.
12.	`B1-66ER`
13.	`B1-66ER`
14.
15.
16.
17.
18.	`B1-66ER`
19.	`B1-66ER`
20.
21.	`B1-66ER`
22.	`B1-66ER`
23.	`upgrayedd`

Fuzz testing

Fuzz testing is a method to find important bugs in software. It becomes more powerful as more computing power is allocated to it.

You can help to test DarkFi by running our fuzz tests on your machine. No specialized hardware is required.

As fuzz testing benefits from additional CPU power, a good method for running the fuzzer is to let it run overnight or when you are otherwise not using your device.

Set-up

After running the normal commands to set-up DarkFi as described in the README, run the following commands.

# Install cargo fuzz
$ cargo install cargo-fuzz

Run the following from the DarkFi repo folder:

$ cd fuzz/
$ cargo fuzz list

This will list the available fuzzing targets. Choose one and run it with:

Run

# format: cargo fuzz run TARGET
# e.g. if `serial` is your target:
$ cargo fuzz run --all-features -s none --jobs $(nproc) serial

This process will run infinitely until a crash occurs or until it is cancelled by the user.

If you are able to trigger a crash, get in touch with the DarkFi team via irc.

Further information on fuzzing in DarkFi is available here.

Troubleshooting

The master branch is considered bleeding-edge so stability issues can occur. If you encounter issues, try the steps below. It is a good idea to revisit these steps periodically as things change. For example, even if you have already installed all dependencies, new ones may have been recently added and this could break your development environment.

Clear out artifacts and get a fresh build environment:

# Get to the latest commit
$ git pull origin master
# Clean build artifacts
$ make distclean

Remove Cargo.lock. This will cause Rust to re-evaluate dependencies and could help if there is a version mismatch.
Ensure all dependencies are installed. Check the README.md and/or run:
```
$ sh contrib/dependency_setup.sh
```
Ensure that you are using the nightly toolchain and are building for wasm32-unknown-unknown. Check README.md for instructions.
When running a cargo command, use the flag --all-features.

contribute.md 9.4 KB Historique Raw