Development and testing guide

Requirements

Before testing, make sure to get your system ready using the Running your QDAO node (dev release) guide.

Testing Tools

Substrate Frontend Template - you can access QDAO node through the template frontend

Polkadot JS - Send signed extrinsics, test execution and auditor signup/challenges. List below.

        pub fn tool_exec_req               // Request audit tool execution
        pub fn tool_exec_cancel_invalid    // Cancel request - to be improved in Milestone 2
        pub fn tool_exec_auto_report       // Record the automated tool's output - to be improved in Milestone 2
        pub fn challenge_report            // Allows challenging an audit report - to be improved in Milestone 2

        pub fn sign_up                     // Signs up as auditor
        pub fn update_profile              // Update the profile
        pub fn cancel_account              // Cancel account
        pub fn approve_auditor             // Approve auditor (otherwise they are not allowed to work)
        pub fn game_result                 // Return ELO game's result

Generating keccak256 hash on linux for auditor pallet testing

$ cat exotestflipper.tar|keccak256

Convert URL from ASCII to HEX for auditor pallet testing

bindechexascii --a2h "https://qrucial.io/"

Online tool: https://www.asciitohex.com/

Testing the auditor sign_up/onboarding workflow

A new user can obtain an auditor status by:

1. The user signs up by calling the sign_up extrinsic which involves locking a certain amount of tokens. Every user which is not already signed up can do this.
2. The AuditorData struct which is assigned to every user holds the auditor's score, which is a Option<u32> and set to None until the auditor is approved.
3. Every user which already has an auditor score which is larger then MinimalApproverScore, a configuralbe runtime constant, can approve new members.
4. As soon as an auditor received approvals from three different existing auditors, his or her score changes to Some(InitialAuditorScore), where InitialAuditorScore is a configurable runtime constant.

At the current point of development, the onboarding/signup workflow of new auditors is primarily tested through extensive unit tests which are defined in: ./qdao-node/audit-pallet/src/tests.rs. These tests cover all aspects of the described onboarding process and prove that our implemented business logic for the extrinsics behaves as expected.

For on-chain testing after compiling and running qdao-node and communicating with it through Substrate Frontend template, we need to start with an existing pre-defined set of auditors which are already capable of approving new auditors. These initial auditors and their initial scores are now provided through the genesis config of qdao-node. The users Alice, Bob and Charlie and Dave are capable of approving the sign-up of new auditors. To test this on chain with the runnning qdao-node, we suggest to call the extrinsics through the Substrate Frontend Template:

1. Try to approve Ferdie by approve_auditor through Alice. Call should fail, since Ferdie did not sign up.
2. Ferdie calls sign_up extrinsic. Should work.
3. Try to approve Ferdie by approve_auditor through Alice. Call should be successful, since Ferdie has signed up now. Second call by Alice should fail, since every applicant can't receive two approvals by the same user.
4. Approval by Bob and Charlie should work.
5. Since now Ferdie obtained auditor status, further attempts to approve Ferdie should fail. Especially Dave will not be able to approve Ferdie, since Ferdie already received three approvals.

Testing the tool execution

After the full node is running, you can test the execution of tools by calling the tool_exec_req function. You can use https://v-space.hu/s/exotestflipper.tar and https://v-space.hu/s/exotest.tar files for testing. Hashes are the following:

$ keccak256 < exotest.tar
0x3e2d46f07bb14bab9d623e426246ee8115f2669fa04745e51a00e18446e47df7
$ keccak256 < exotestflipper.tar
0xa03f6ba3eb8141f0f8daee4ea016d4144f44fc4cba9e7477a4c1f041aaeb6c38

1. Exosysd monitors the execution of tool_exec_req extrinsic. When it is called successfully, the off-chain tool execution gets requested by exosysd. The url parameter is the file provided for audit and the hash it the keccak256 hash of it. If you send this extrinsic two times, the second should fail as the security audit's unique identifier is the audit file's keccak256 hash itself.
2. After successful call of tool_exec_req, Exosysd passes the url and the hash to exotool.sh.
3. exotool.sh runs exec_audit takes the output, executes the default tool cargo audit (this tool will be replaced in M2).
4. lar.py sends a notification extrinsic to QDAO blockchain through notify_logger call. This includes the hash and the result of the tool execution. With this the execution logic finishes.

The extrinsics tool_exec_cancel_invalid will be used to cancel invalid executions, but this extrinsic might be removed as the blockchain itself doesn't have direct control over the execution (exosysd and exotool do). We will test it in M2 for the best possible solution.

The tool_exec_auto_report extrinsic is used by lar.py to report on the status of audits. At this moment this can be called manually as well from the frontend.

The challenge_report provides option for the auditors to challenge each other. This is a feature to be improved in M2.

Overall, the execution flow is the following:

ExoSysD is monitoring continously and lar.py is running as the logger.

Flow:
    Audit request success --> ExoSysD calls ExoTool for execution of automated audit
    ExoTool handles the automated execution and reports the status to lar.py
    lar.py logs the event and sends an extrinsic to the blockchain about the status.