Dakar

Dakar is a blockchain forensics application, focusing on the analysis of CoinJoin transactions. It consists of a backend implemented in Go and web app written in Vue 3 with the Vuetify UI framework.

The backend ingests blockchain data via RPC connections to blockchain clients and performs transaction classification and address clustering on it.

The web app allows exploring the ingested and transformed data. Additionally, graph based editor enables viewing relationships between transactions and address clusters. Several CoinJoin analysis modules are available: heuristics, transaction similarity measure, mixing activity overview and more.

Get Started

Set up Blockchain Client

• Setup either dashd or bitcoind
• Configure the RPC connection and set the details in config.yml of Dakar

Setup Dgraph

• Change to the docker directory
• Change the whitelisted ip range in docker-compose.yml to include your private docker container ip
• Set the appropriate values in the .env file
• Execute docker compose up to start Dgraph and its auth stack
• After the startup is complete the database explorer Ratel is available via http://localhost:8000/?local

Setup Dakar

• Build Dakar

cd backend
make dakar
cd build

• Create a new config file. Change the values in the newly generated config.yml to appropriate values.

# -createConfig will create a new config file `config.yml` in your current directory
./dakar -createConfig

• Launch the Dakar executable with the following command

# -reset will delete all data of the dgraph instance and setup a new schema
./build/dakar -reset

• The REST API can be accessed via the address printed in the standard output. Check the Dakar description for more details.

Docker

To create a docker image containing the Dakar executable execute the script below.

make docker

The image expects the config file to be mounted to /data/config.yml.

Setup Frontend

• Switch to frontend folder cd app
• Start dev server yarn dev

Metrics

Metrics are exposed via /metrics on a separate port, which is configurable via the config file.

Running local tests

Some tests require a connection to a dgraph database or a blockchain RPC client.

The command below runs all tests, which don't require a database or RPC connection.

make test

To run database tests, first set up an empty dgraph instance, preferably via docker. Set the DB_TESTS and DB_HOSTNAME environment variables to run database tests. DB_HOSTNAME should be set to the host which runs the database. The port is expected to be 9080.

export DB_TESTS=1; export DB_HOSTNAME=0.0.0.0; make test

Set the DB_TESTS, DB_HOSTNAME, RPC_TESTS and RPC_HOSTNAME environment variables to run all tests.

export DB_TESTS=1; export RPC_TESTS=1; export DB_HOSTNAME=0.0.0.0; export RPC_HOSTNAME=0.0.0.0; make test

Additionally, the Dgraph ACL user and password can be configured via DB_USER and DB_PASSWORD.

Environment Variable	Description
DB_TESTS	Set to enable database tests
DB_HOSTNAME	The hostname of the dgraph test database
DB_USER	The ACL user name (default: groot)
DB_PASSWORD	The ACL password (default: password)
RPC_TESTS	Set to enable blockchain RPC tests
RPC_HOSTNAME	The hostname of the blockchain RPC client

OpenAPI Documentation

The API documentation is built with swaggo using the annotations in the api file.

The following command

• compiles the OpenAPI schema the in openapi directory
• builds the Typescript client
• and publishes it to the Gitlab registry.

make openapi-spec && make openapi-client && make openapi-publish

Make sure to have the deployment token set in your ~/.yarnrc.yml:

yarnPath: .yarn/releases/yarn-4.0.0.cjs

npmScopes:
  blockchain:
    npmRegistryServer: "https://<gitlab_host>/api/v4/projects/410/packages/npm/"
    npmAlwaysAuth: true
    npmAuthToken: "<your-deploy-token>"

Format the OpenAPI annotations using:

make openapi-fmt

Development

1. Don't introduce new dependencies unless discussed with the maintainer
2. Propagate and wrap errors.
   1. Propagate errors with additional information up to the main package and log them there. Do not log errors in other package than main. Only log if there is an error. Do not log metrics.
   2. Wrap all native errors via the StackError type to enable error tracing.