Architecture

Detailed tech topology of QDAO

ExoSys, the core of QDAO

ExoSys is responsible for the following:

• Handle audit requests
• Handle the QRD coin transactions
• Mint the non-transferrable dynamic NFTs of audits
• Uses QDAO's main storage
• Work together with the audit pallet
• Work together with the membership pallet

ExoTool

Prerequisites

• docker
• docker compose (might be useful to have this too, would possibly remove some user errors)

Standalone run

1. git clone the repo https://github.com/Qrucial/QRUCIAL-DAO.git
2. cd into ./QRUCIAL-DAO/exotools/ directory
3. run the command docker build -t exotools ./dockerfiles/
   • this builds the image based on the instructions in the dockerfile at ./dockerfiles/
4. make the local audit dir mkdir auditdir
   • this directory is the shared point between the docker and your file system.
5. run the command docker run --name=auditor -v $(pwd)/auditdir:/auditdir exotools
   • Run a container named "auditor" based on the image exotools.
   • mount the local folder "auditdir" to the remote folder "/auditdir"
6. to run it again use the command docker start -a auditor
   • this runs the same script and shows the output in the terminal
7. to execute specific commands run docker exec <...>

ExoTool Experimental ideas

• If we want to run many of these containers in parallel we might have to worry about performance at some point. I believe that using docker <pause/unpause> would be the best solution as far as we know, but to do this we would have to have some sort of scheduler that monitors resource usage and pauses/unpauses accordingly
• Make each started container have a unique hash based on the current thing that needs to be audited.
  • this would allow us to easily run many in parallel and see what container is working on what file.
  • something like: XTPATH=audit_files/"$HASH""_$(date +%s)" where HASH = a 512sha hash of the file.

Lar.py - API - Event forwarder, reporter and storage

What is it?

HTTP API.

What does it do?

1. The logger gets notified by ExoTool about audit results: success or fail, details. It sends an extrinsic to the blockchain node about the result, using the the ExoTool SS58 key.

2. Stores the results in json format.

3. Sends extrinsics to ExoSys.

4. Provides the reports through HTTP service.

How does it connect to other parts of the system?

• Input coming from ExoTool
• Extrinsics are sent to ExoSys
• External users can request reports through the HTTP service.

Audit reporting and challenging, reputation system

1 QRD = 1 MUNIT

Logic

1. User with QRD requests the audit:
   • URL to tar package, including the project to be audited
   • Hash of the package for verification (for small packages we'll experiment with hashing on the FE)
2. The QDAO node triggers an event which is caught by the ExoSys Daemon
3. The Deamon initiates the auditor srcipt (exotool.sh), which is utilizing docker to run all tools
4. When OffChain execution finishes, lar.py receives an API POST from exotool.sh and sends the results to it.
5. Lar.py sends saves the logs, the report files and sends an extrinsic to the blockchain about the result:
   • Success, call params:
     • Review hash
     • Type: automated or manual testing
     • Vulnerabilities
       • Risk score (u8, 0-9 misc, 10-19 low, 20-29 medium, 30-39 high, 40-49 critical)
       • Classification enum (u16, eg. 1 is Reentrancy, 0 is custom and to be classified)
         • Solidity example: https://github.com/crytic/slither#detectors
       • Description (max 4kiB text)
   • Invalid (in this case, 80% of the QRD is returned to the requestor, 20% is burned)
6. The result meta is saved onchain. Files are stored by on Lar.py instances.
7. The result can be immediately challenged by other auditors:
   • Another auditor whose score is above 700 can challenge anyone, risking reputation and 100 QRD
   • A link and a hash needs to be sent along with the challenge request:
     • Link to the information package about the claims, eg. what is wrong or missing in a .txt document
     • Audit hash, Auditor to be challenged, vulnerability ID, patch(remove, add, modify)
   • The report challenge is live until council decides to close it
   • ELO score is counted based on the result